01 ZXG10 BSC Troubleshooting Manual

ZXG10-BSC Troubleshooting Manual
(Manual version 20041010-R1.0)
ZTE CORPORATION
Preface
This manual covers the routine maintenance of ZXG10-BSC and is a guide to BSC (including GPRS)
and OMCR routine maintenance and troubleshooting. It introduces the symptom, cause, and
troubleshooting of common faults. With it, the maintenance personnel can locate and handle a fault
quickly and efficiently. This manual is applicable to each version of ZXG10-BSC.
This manual consists of the following four chapters and three appendices:
Chapter 1 Provides the BSC (including GPRS) concerned fault analysis and troubleshooting.
Chapter 2 Provides the OMCR concerned fault analysis and troubleshooting.
Chapter 3 Provides the service concerned fault analysis and troubleshooting.
Chapter 4 Gives some BSC maintenance experience.
Appendix A Introduces the board and component replacement.
Appendix B Describes the configuration file ZXG10.CFG.
-i-
Appendix C Describes the configuration file TCPIP.CFG.
This manual provides the analysis and isolation of only some common faults. The maintenance
personnel shall contact ZTE CORPORATION, make enough preparations and keep a record for the
significant operations like version upgrade.
Statement: The actual product may differ from what is described in this manual due to
frequent update of ZTE products and fast development of technologies. Please contact
the local ZTE office for the latest updating information of the product.
-ii-
Contents
CHAPTER 1 BSC TROUBLESHOOTING............................................................................................. 1
1.1 BSC TROUBLESHOOTING............................................................................................................... 1

1.1.1 PP Not Setting Up Link..................................................................................................... 1
1.1.2 Alarm Indicator on PP Being ON..................................................................................... 2
1.1.3 DSNI Switchover................................................................................................................. 3
1.1.4 STB Faulty........................................................................................................................ 4
1.1.5 All SS7 Links Broken......................................................................................................... 5
1.1.6 A-interface Circuit Unassembled and Blocked.................................................................. 7
1.1.7 BATC Startup Failure......................................................................................................... 8
1.1.8 BSC Startup Failure after T Network Reset.......................................................................... 9
1.1.9 Active/Standby MPs Switchover......................................................................................... 11
1.1.10 MP CPU Overload Alarm................................................................................................. 12
1.1.11 Alarm Indicator on MP Flashing or Being ON.................................................................. 14
1.1.12 Newly Added Peripheral Module Exceptional.................................................................. 15
i
1.1.13 Failure in Sending Data to Foreground after Addition of New BSC.................................. 16
1.2 GPRS TROUBLESHOOTING........................................................................................................... 17
1.2.1 Interruption on Gb Interface due to Transmission Error...................................................... 17
1.2.2 GPRS Transmission Failure due to CRC............................................................................. 21
1.2.3 NSVC on Gb Interface Faulty............................................................................................. 24
1.2.4 GPRS Service Unavailable................................................................................................. 25
1.2.5 MS Browsing Failure......................................................................................................... 26
1.2.6 PS Channel due to Absence of Frame Number.................................................................. 27
CHAPTER 2 OMCR TROUBLESHOOTING......................................................................................... 29
2.1 SERVER TROUBLESHOOTING...........................................................................................................29

2.1.1 Repeated Server Process Startups..................................................................................... 29
2.1.2 File System of a Server Partition Damaged.......................................................................... 30
2.1.3 Synchronization of Background with Foreground after Recovery from Link Interruption of
OMC Server................................................................................................................................ 33
2.1.4 Database –1 Error............................................................................................................. 34
2.1.5 Failure in Automatic Oracle Startup................................................................................. 35
ii
2.1.6 Oracle Client Not Supporting Processing in Chinese.......................................................... 36
2.2 CLIENT TROUBLESHOOTING........................................................................................................... 37
2.2.1 Failure in Finding DLL..................................................................................................... 37
2.2.2 Process Exception............................................................................................................. 38
2.2.3 Failure in Opening Resource File *.res............................................................................. 39
2.2.4 Failure in Opening Help File............................................................................................. 40
2.2.5 Failure in Logging on to Main Window............................................................................. 41
2.2.6 Main Window Having No Background............................................................................. 42
2.2.7 Failure in Retrieving topo Tree......................................................................................... 43
2.2.8 Failure in Refreshing topo Tree......................................................................................... 46
2.2.9 Signaling Traced in Illegible Code..................................................................................... 47
2.2.10 Failure in Connecting DIF with Database.......................................................................... 48
2.2.11 Failure in Link Setup Between Client and Server.............................................................. 49
2.2.12 Client FTP Failure............................................................................................................. 50
2.2.13 Failure in Link Setup Between MPCOMM and Foreground..............................................51
2.2.14 Error in Initial Version Re-installation............................................................................. 52
2.2.15 Client Exception after Link Interruption and Recovery Between Foreground and
iii
Background.................................................................................................................................... 53
2.2.16 Alarm Not Reported after Manually Cleared...................................................................... 54
2.2.17 Error in OMCR Backup Import......................................................................................... 55
2.2.18 Error in OMCR Installation............................................................................................. 56
2.2.19 Failure in Sending Big Transaction due to BTS Modification.......................................... 57
2.2.20 Log Query Timeout......................................................................................................... 58
2.2.21 Log Query Failure............................................................................................................. 59
2.2.22 Virus Problem................................................................................................................. 60
CHAPTER 3 SERVICE TROUBLESHOOTING..................................................................................... 61
3.1 DIFFICULT TO MAKE CALL........................................................................................................... 61

3.2 MONOLOG DUE TO TRUNK BLOCKING........................................................................................... 63
3.3 TRAFFIC OVERLOAD....................................................................................................................... 65
3.4 CALL EXCEPTION AFTER BCC MODIFICATION........................................................................... 66
3.5 FAILURE IN NETWORK ACCESS UNDER NORMAL NEW BTS....................................................... 67
3.6 CALL DROPPED........................................................................................................................... 68
3.7 CALL EXCEPTION AFTER BCCH CARRIER FREQUENCY CHANGE............................................... 69
iv
CHAPTER 4 MAINTENANCE EXPERIENCE..................................................................................... 71
4.1 PERIODIC VIEW OF FOREGROUND PRINTED FILES....................................................................... 71

4.2 BLOCK AND UNBLOCK BEFORE TIMESLOT/CHANNEL COMBINATION........................................... 72
4.3 MAKING LOG FILE PRINT UNAVAILABLE....................................................................................... 73
4.4 HANDLING A-INTERFACE CIRCUIT STATUS EXCEPTION – NOT MOUNTED ON MSC................... 74
4.5 MATTERS TO ATTENTION OF BSC WITH EDRTS........................................................................... 76
APPENDIX A BOARD AND COMPONENT REPLACEMENT.......................................................... 77
APPENDIX B ZXG10.CFG................................................................................................................. 85
Appendix C TCPIP.CFG..................................................................................................................... 89
v
Chapter 1 BSC Troubleshooting
1.1 BSC Troubleshooting
1.1.1 PP Not Setting Up Link

 Symptom
A PP board did not set up a link.
 Analysis and troubleshooting
Check the data. Switch over PP boards, HW cables, DSN boards and BOSN boards. Replace the faulty
board.
ZXG10-BSC (V2) is a hierarchical management structure. A fault in one of the following boards can
cause a PP not to set up a link:
TIC under the management of GPP. It communicates with gpp 485.
DRT under the management of GPP. It communicates with gpp hdlc.
GPP under the management of MP. It communicates with mp hdlc.
1
GDPP under the management of PUC. It communicates with puc hdlc.
PUC under the management of MP. It communicates with mp hdlc.
1.1.2 Alarm Indicator on PP Being ON

 Symptom
The alarm indicator on a PP board was ON.
 Analysis
The alarm indicator on a PP board is ON when the clock of the board is lost.
 Troubleshooting
Check the HW cable of the PP board on the backplane.
2
Chpater 1 BSC Troubleshooting
1.1.3 DSNI Switchover

 Symptom
Peripheral PP boards were exceptional.
The exceptional PP boards were under one pair of DSNIs. The standby DSNI was faulty.
DSNI switchover occurred.
 Analysis
A hardware fault in a standby DSNI can interfere in the output of 8M clock signals. The clock input to a
GPP will be exceptional and the GPP will reset in this case.
 Troubleshooting
Replace the faulty DSNI.
3
1.1.4 STB Faulty

 Symptom
There appeared many alarms like SS7 L3 alarm, SP not reachable, SMB faulty, DRT/EDRT alarm, and
DTI alarm. The run indicator on the STB did not flash normally. The red indicators on all the SMB, DTI,
and DRT boards were ON. The system breakdown occurred. The run indicators on the MPPP and DSN
did not flash normally. However, the run indicator on the MP flashed normally. The MP gave no alarm.
The active/standby MPs were not switched over.
 Analysis
The engineers viewed the related alarms and foreground files printed. They found that the STB reset
every half hour or so and that the OE Error message had been printed many times before the system
breakdown. This indicated other boards were also exceptional. The engineers determined that a
hardware fault in the STB caused faults on the DSN.
 Troubleshooting
Replace the faulty STB.
4
1.1.5 All SS7 Links Broken
 Symptom
The MSC could not reach the BSC signaling point (SP). The 12 links were all out of service. The ERR
indicators on the two SS7 COMM boards were ON.
1. The ERR indicators were still ON when the SS7 COMM boards reset.
2. The ERR indicators were still ON when the MPs on the central module were switched over.
3. The ERR indicators were still ON when the SS7 COMM boards were replaced.
4. The ERR indicators were OFF when the BOSNs were switched over. Four of the links were activated
in this case. However, no call could be made. All location update requests were found rejected within 15
minutes through MSC signaling tracing.
5. The fault still existed when the MPs on the central module and BOSNs were switched over repeatedly.
6. The fault was recovered in about five minutes after the MP on the central module reset.
 Analysis
The engineers determined that the second MPPP met with a hardware fault and was unstable.
 Troubleshooting
5
Replace the faulty MPPP.
6
1.1.6 A-interface Circuit Unassembled and Blocked

 Symptom
An A-interface circuit was unassembled and blocked.
 Analysis
One of the following can cause an A-interface circuit to be unassembled and blocked:
 The A-interface circuit data on the BSC is not consistent with that on the MSC.
 The BSC has trouble cooperating with the MSC from another manufacturer.
 Troubleshooting
Check whether the PCMINO and CICNO on the BSC are consistent with those on the MSC.
7
1.1.7 BATC Startup Failure
 Symptom
A BATC could not be started.
HW cables are assigned to BATC frames in the sequence of addition of the BATC frames (HW5 and
HW5 are assigned to the first added BATC frame and HW7 and HW8 to the second). The cable
connection on the BSC backplane also follows that sequence.
The configuration will be inconsistent with the cable connection on the BSC backplane when the
configuration does not follow the sequence. The BATC frames cannot be started normally in this case.
For example, the BATC frames cannot be started normally when you add two BATCs with the lower
before the upper.
BIF
BRRM
BSCM
BNET
BATC (HW5, HW6) assigned first
8
BATC (HW7, HW8)
9
1.1.8 BSC Startup Failure after T Network Reset
 Symptom
Some BTSs were difficult to access. It was found that there were many access requests on the Abis
interfaces while no on the A-interface through signaling tracing of the BTSs. There were no paging
messages from the MSC or access request messages from the BSC. There were only SP test messages
and uplink unknown A-interface messages.
The engineers implemented signaling tracing of two SS7 links of BSC1. They found neither link carried
paging and connection messages that should have existed.
The signaling tracing of BSC2 was normal.
The engineers observed the MTPs on BSC1 and found their green indicators flashed normally. They
observed the A_TRUNK using a data probe and found it also in the normal state.
The engineers had a suspicion of that the SS7 links were false active. They removed the two MTPs and
re-inserted them. The MTPs started normally. However, the engineers found the fault still existed
through signaling tracing.
The engineers dissembled the SS7 links and re-assembled them. They found the fault still existed
10
through signaling tracing.
The engineers reset the two MTPs again. However, the fault was not recovered yet.
The SS7 links from the switch to the BSC reported GS alarms to the NMS of the switch. The packet loss
rate reached 98% on either SS7 link.
The engineers reset the standby MP on the SCM. They switched over the MPs on the SCM five minutes
later. BSC1 SCM link interruption was found in the OMCR. About five minutes later, the problem
disappeared and the A-interface was found recovered through signaling tracing.
 Analysis
1. Data configuration error in the OFFICE table can fail BSC startup.
BSCSPTYPE shall be 1 (that indicates a SP) rather than 3 (that indicates a STP). BSCSPTYPE being 3
can fail the startup of the SP.
2. A too small T3 in the TIMER table can fail BSC startup.
The active/standby switchover can cause global reset when the T3 is too small. The global reset can fail
the startup of the BSC.
 Troubleshooting
1. Set BSCSPTYPE to 1 rather than 3.
2. Set T3 in the TIMER table to 10 seconds.
11
1.1.9 Active/Standby MPs Switchover
 Symptom
The run indicator on the active MP did not flash. The BSC (V2) system automatically implemented
active/standby MPs switchover. The engineers reset the previous active MP and switched it back to the
active state. The system still implemented active/standby MPs switchover automatically.
 Analysis
The fault may lie with the disk. In this case, the active MP automatically resets and the standby MP
works instead to avoid MP dead lock and service breakdown. The file system on the previous active MP
may meet with a certain degree of damage and cannot work stably any longer.
 Troubleshooting
Replace the faulty MP.
12
1.1.10 MP CPU Overload Alarm
 Symptom
There appeared an "MP CPU overload" alarm in the background alarm system. The engineers observed
the foreground and found the run and RES indicators on the MP were respectively ON and OFF. The
background could not communicate with the MP normally through the OMCFTP command. The run and
RES indicators on the MP were still exceptional when the MP reset.
The engineers implemented the following:
1. They installed the display, display adapter, and keyboard and restarted the MP.
2. There appeared a "Hard disk boot failure. Please insert a floppy disk and boot from it" message. Press
<Enter> to proceed.
3. They started the DOS program and ran a command when the MP entered the working state of the
version. The MP responded very slowly. It displayed the response on the display more than 10 seconds
later.
4. They entered SETUP, re-scanned the hard disk, and restarted the MP.
5. They observed the MP when the version came into operation. They found that the run indicator
flashed every 40 seconds and the RES indicator was ON.
13
6. They observed the MP two hours or so later. They found the run and RES indicators worked normally.
The background alarm system indicated the alarm was cleared. They found the MP was normal through
the OMCFTP and MPINFO commands.
 Analysis
The cause of the fault is that the file system on the MP was unstable. However, it cannot be said that a
hardware fault occurred to the hard disk. Each power-off or reset can cause some clusters to be lost. The
file system may become exceptional when accumulated clusters have been lost.
 Troubleshooting
Replace the faulty MP.
14
1.1.11 Alarm Indicator on MP Flashing or Being ON
 Symptom
The alarm indicator on a MP flashed or was ON.
 Analysis
This symptom possibly results from a bus fault. The cause may be that some board on the control shelf
is not tightly inserted or is faulty. The MP prints an OE Error message with an address in this case. With
the address, you can determine which board the problem lies with.
D000 --- D0FF: SMEM
D100 --- D1FF: the first COMM
D200 --- D2FF: the second COMM
 Troubleshooting
Insert the problem board tightly or replace it.
15
1.1.12 Newly Added Peripheral Module Exceptional
 Symptom
A newly added peripheral module could not work normally.
1. Check the related cables.
2. Check whether the data of the new module is added to the file tcpip.cfg on the central module.
16
1.1.13 Failure in Sending Data to Foreground after Addition of New BSC
 Symptom
Sometimes data could not be normally sent to the foreground after a BSC was newly added in the
background.
 Analysis
The data of a newly added BSC is incremental data in BSS (V2). A MP has been commissioned and
contained data on the production line. The new incremental BSC data collides with the data in the MP
and cannot be sent to the MP.
 Troubleshooting
Clear the MP, restart it and then send the data.
17
1.2 GPRS Troubleshooting
1.2.1 Interruption on Gb Interface due to Transmission Error

 Symptom
A Gb interface met with interruption and the GPRS subscribers could not gain access to the network.
 Analysis
The BSC and SGSN were connected through a frame relay switch. They acted as user sides on the UNI
interfaces on the entire frame relay network. The BSC was in a place and the SGSN and switch in the
other place. The BSC was relatively far from the switch.
The following figure shows the BSC, switch and SGSN.
Transmission
Place II Place I
18
The engineers connected a K1297 signaling application to A and found the following. The FR signaling
procedure between the BSC and switch was normal. The BSC sent STATUS ENQ messages to the
switch periodically. The switch responded with proper STATUS messages. However, the SGSN did not
respond with NS Alive Ack messages to the NS Alive messages from the BSC. The engineers sent a NS
Reset message from the BSC forcedly. The SGSN responded with a proper NS Reset Ack message.
However, the BSC still sent NS Reset messages repeatedly for a certain time and then sent NS Alive
messages periodically. It appeared that the BSC had not received the NS Reset Ack message from the
SGSN. The SGSN sent NS Alive messages to the BSC after responding with the NS Reset Ack message.
The BSC responded a NS Alive Ack message occasionally. The SGSN stopped sending the NS Alive
Ack message when it sent four (ten as specified in ETSI 08.18) successive NS Alive messages while
received no response from the BSC. The SGSN did not respond to the NS Alive messages from the
BSC. The engineers repeated the previous operation. The previous results repeated. The transmission
from the SGSN to the BSC was unstable.
The engineers connected the K1297 signaling application to B and found the following. There were
CRC errors in most downlink data frames from the SGSN or switch to the BSC. Some signaling
19
messages even missed some essential information elements and could not be decoded normally. The
engineers reset the corresponding board on the BSC. The problem still existed. The BSC discarded the
data frames with CRC errors. Therefore, most signaling messages or responses from the SGSN or switch
to the BSC could not be decoded due to CRC errors. That was why the engineers found the previous
results at A.
In conclusion, a fault in the transmission from place I to place II caused the downlink signaling from the
SGSN to meet with CRC errors on the BSC side.
The engineers made a self-loop detection of the E1 cable on the BSC side at B. The self-loop test was
passed. They then made a self-loop detection of the E1 cable on the BSC side at C. The self-loop failed.
The engineers preliminarily determined that a transmission fault at C caused the high downlink BER They
re-welded the cable lug at C and made a second self-loop detection at C. The self-loop test was passed. The
engineers stopped self-loop detection and reset the FRP. They found the Gb interface was recovered. The
main cause of the interruption on the Gb interface was the poor welding quality of the cable lug at C.
 Troubleshooting
Repair the cable lug at C to ensure the normal transmission.
20
1.2.2 GPRS Transmission Failure due to CRC
 Symptom
A TIC reported a "peer out of frame" alarm when the Gb interface was normal. The indicator on the TIC
did not flash. The transmission failed.
 Analysis
The BSC and SGSN were connected through a frame relay switch. They acted as user sides on the UNI
interfaces on the entire frame relay network. The BSC was in a place and the SGSN and switch in the
other place. The BSC was relatively far from the switch. The following figure shows the BSC, switch
and SGSN.
Transmission
Place II Place I
The engineers made a self-loop detection of the BSC at A. The self-loop test was passed. They made a
21
self-loop detection of the SGSN at B. The self-loop test was also passed. They tested the transmission
using a BER tester at the same time. The BER was satisfactory. The transmission recovered. The NSVC
turned in the blocked state several hours later. The indicator on the TIC did not flash. This indicated the
physical layer had failed. The bottom layer (physical layer) of a DTI on the MSC functions the same as
that of the TIC. The engineers led the GPRS transmission to a DTI on the MSC and found the indicator
on the DTI was also exceptional. Therefore, the cause of the physical layer failure was not a hardware
problem on the BSC.
The engineers together with the technical personnel from MOTOROLA (the manufacturer of the peer
equipment) replaced the switch port at A through which the BSC was connected with the switch. The
fault still existed. The fault did not lie with the switch port at A. The engineers observed the signaling
procedure at B and found the following. The frame relay sent STATUS ENQ messages to the SGSN
every ten seconds and received proper STATUS PDU messages from the SGSN. However, the frame
relay reported network errors or equipment faults to the NSVC at times. The NSVC sent a NS_BLOCK
message to the SGSN and the SGSN returned a NS_BLOCK ACK message. The NSVC link turned in
the blocked state. Therefore, it was not a fault in the NSVC link.
The engineers then simulated the commissioning scenario. The MOTOROLA personnel stopped CRC.
The Gb interface was recovered. The indicator on the TIC flashed normally. The background alarm
22
disappeared. Therefore, the cause of the fault was CRC. CRC is essential to GPRS functions according
to the protocol. However, different CRCs shall be implemented for different kinds of signaling. There
are two kinds of signaling for packet data services: common channel signaling and channel associated
signaling. For common channel signaling only the upper layer requires CRC and the bottom layer does
not. For channel associated signaling the physical layer requires CRC. ZTE's equipment utilizes the
common channel signaling while MOTOROLA's equipment utilizes the channel associated signaling.
The difference in understanding of the protocol between the parties caused the CRC failure. The NSVC
services were blocked and the indicator on the TIC did not flash.
 Troubleshooting
Request MOTOROLA to cut the CRC to ensure the long normal operation of the equipment.
23
1.2.3 NSVC on Gb Interface Faulty

 Symptom
The NSVC link on the Gb interface was found faulty through dynamic data management.
1. Check that there is no alarm related to a GPRS board in the OMCR.
2. Check that the transmission on the SGSN is normal through self-loop detection of the SGSN.
3. Check that the NSVC on the BSC side is normal through self-loop detection of the BSC. There shall
appear a transient "NSVC normal" in the dynamic data management system.
4. Reset the FRP and check that there is NSVC data on the FRP.
5. Check the HW cables between the PUC and DSNI. They shall be in good conditions. Their connectors
shall be in good contact. They shall be consistent with the background configurations.
6. Check whether there has been any data modification.
24
1.2.4 GPRS Service Unavailable
 Symptom
A MS could not perform an attach event. The GPRS services were unavailable.
1. Check that the MS supports GPRS and that its SIM card has subscribed to GPRS services.
2. Check that the host cell supports GPRS and is configured with the channels.
3. Check whether the BRP carries the data of the cell. If no, reset the BRP.
4. Check whether the FRP carries BVCI data and is normal. If no, reset the FRP.
5. Switch over the active/standby PUCs.
25
1.2.5 MS Browsing Failure

 Symptom
A MS could not browse a web page.
 Analysis
Make sure that the MSs under the other BSCs of the SGSN can browse the web page.
 Troubleshooting
Follow the troubleshooting procedures in Section 1.2.3 and 1.2.4 in this manual.
26
1.2.6 PS Channel due to Absence of Frame Number

 Symptom
A PS channel was blocked due to absence of frame number.
 Analysis
A PS channel is blocked when the corresponding BRP has not received frame numbers from CHP
periodically. The fault normally lies with the path from the CHP to the BRP.
 Troubleshooting
The current version of equipment supports self-recovery of some blocking faults. For example, the
program initiates a recovery procedure when it finds inconsistency between PN and BRP or between PN
and BTS. This normally occurs to a dynamic channel. Implement the following for a fault unable to
experience self-recovery. Switch over the BRPs. Reset the standby PUC. Switch over the PUCs. Reset
the BOSN. Switch over the BOSNs.
27
Chapter 2 OMCR Troubleshooting
2.1 Server Troubleshooting
2.1.1 Repeated Server Process Startups

 Symptom
Nothing was returned in response to OMCPS query in the directory maintenance system.
The cause of the fault is normally that the OMCSTART process runs repeatedly.
Check whether there are multiple GPO processes through $ps –uomc.
If so, kill all the GPO processes through $kill –9 PID (PID of the GPO to be killed).
Check that all processes are quitted and then restart.
29
2.1.2 File System of a Server Partition Damaged
 Symptom
The file system of a Server partition was damaged when the Server met with unexpected shutdown (for
example due to outage). It failed to recover automatically when the Server restarted. The system could
not work normally.
1. Recover the fault manually through fsck after startup from the hard disk. The system will prompt you
to enter the root password for maintenance when it fails to recover the fault automatically. Enter the root
password. Enter "init 1" at the # prompt and press <Enter>. Enter "fsck –y" at the next # prompt. Handle
the problems according to requirements. Restart the Server through reboot.
2. Try recovering the fault manually after startup from an optical disk if the fault cannot be recovered
through the previous step.
Insert the "install" or "software 1 of 2" disk in the optical drive. Do not insert a wrong disk, especially
do not mistake "software 2 of 2" as "software 1 of 2". The system will fail to restart and return to the
"ok" prompt if you insert a wrong disk. You will not eject the wrong disk until you restart the computer.
Press <stop+A>. An "ok" prompt appears on the display. Enter "boot cdrom –s" at the prompt and press
30
<Enter>. The system will restart from the optical disk. Wait until the # prompt appears. Enter "fsck
/dev/rdsk/c1t0d0*" ("c1t0d0*" is to recover all partitions on the first hard disk and "c1t1d0*" to recover
those on the second hard disk) at the prompt and press <Enter>. Restart the Server through reboot. The
Server will restart automatically from the hard disk. You need not remove the optical disk.
3. The cause of the fault may be that sometimes the partition cannot be automatically mounted. You can
mount it manually.
Enter "df –k" and press <Enter>. Check whether the partition is listed. If no, mount the partition
manually through mount point of the partition, for example, mount/dev/dsk/c1t0d0s7 /export/home.
4. You have to re-install the Server if the fault cannot be recovered through the previous steps.
Therefore, it is important that you shall back up data modifications on a Client at times to prevent data
loss due to startup failure. Determine which partition the damaged file system belongs to and re-install
the corresponding software. For example, re-install only omcr when the partition c1t0d0s7 of
/export/home is damaged. Re-install oracle and omcr when the partition c1t1d0s7 of /oracleapp is
damaged.
1) Re-create the damaged file system through newfs, for example, newfs /dev/dsk/c1t0d0s7. All data in
the partition will be lost.
2) Mount the mount point to the partition of the new file system. For example, mount
31
/dev/dsk/c1t0d0s7/export/home.
3) Install the related software and restore the backup data.
32
2.1.3 Synchronization of Background with Foreground after Recovery from Link

Interruption of OMC Server
 Symptom
A "common fault in operation" or "transaction cancelled" message was displayed after some operations
on the Client. The operations failed after you confirmed the message.
The following error message was traced in the trace system on the OMC Server:
agt:
LAF: Transaction Cancel Because FBSYNC
 Analysis
The cause of the fault may be synchronization of the background with the foreground. The background
implements synchronization with the foreground after the interruption and recovery of a logical link
between the foreground and background (of a module on a BSC). All operations of the BSC are rejected
during the synchronization.
 Troubleshooting
Wait until the synchronization of the background with the foreground (of the module on the BSC)
completes. Restart the OMCR process if the link has not been set up for 20 minutes.
33
2.1.4 Database –1 Error
 Symptom
The system displayed a "database –1 error" message when you added a board and imported the software
into the database.
The cause of the fault may be that the data sequence is not altered after imported into the database.
Arrange the database through altermoinfosequence.sql in the background.
34
2.1.5 Failure in Automatic Oracle Startup
 Symptom
Oracle could not be started automatically.
Check whether the dbora file is configured according to automatic startup.
The ORA_HOME shall be in accordance with the actual installation directory.
35
2.1.6 Oracle Client Not Supporting Processing in Chinese

 Symptom
The results queried in Chinese on an Oracle Client were displayed as illegible codes.
 Analysis
The cause of the fault is that the character set on the Client is inconsistent with that on the Server.
 Troubleshooting
1. Enter "regedit" in the Run window to start the registry editor.
2. Find HKEY_LOCAL_MACHINE-->SOFTWARE-->ORACLE.
3. Find the item of NLS_LANG.
4. Modify the string to AMERICAN_AMERICA.WE8ISO8859P1.
5. Restart the Oracle Client.
36
2.2 Client Troubleshooting
2.2.1 Failure in Finding DLL

 Symptom
The system displayed a "Cannot find DLL" message when you started uisf.exe.
1. Check whether the value of the environment variable OMCHOME is consistent with the directory of
uisf.exe and whether the path of $OMCHOME\lib is added to the environment variable PATH.
2. Sometimes uisf.exe and other Client processes have started. However, the message still appears when
a process starts. The cause of the fault may be that the DLL mentioned in the message does not exist in
$OMCHOME\lib.
37
2.2.2 Process Exception
 Symptom
A process was exceptional.
Check whether there are DLL files such as afsm.dll and vosdll.dll on the hard disks of the computer.
This is to see whether there is another version of OMCR (V2) Client on the computer. If so, delete the
OMCR (V2) related DLL files from other directories. Restart the Client. Locate other causes if the fault
still exists.
38
2.2.3 Failure in Opening Resource File *.res
 Symptom
The system displayed an "Opening the resource file *.res failed" message when you started an
application process on a Client.
Check whether the environment variable OMCLOCALE is set to CHINESE (or left blank) and whether
the mentioned *.res file exists in $OMCHOME/locale/chinese if the version is in Chinese.
Check whether the environment variable OMCLOCALE is set to English and whether the mentioned
*.res file exists in $OMCHOME/locale/english if the version is in English.
39
2.2.4 Failure in Opening Help File
 Symptom
The system displayed an "Opening the help file *.htm failed" message when you clicked <Help> of an
application process on a Client.
Check whether the mentioned directory is $OMCDOC/chinese and whether the mentioned file exists in
the directory if the version is in Chinese.
Check whether the mentioned directory is $OMCDOC/english and whether the mentioned file exists in
the directory if the version is in English.
40
2.2.5 Failure in Logging on to Main Window

 Symptom
The system displayed a "Cannot receive login message from the Server. The program aborts" message
30 seconds or so after you entered your user name and password in the Login window.
Isolate the fault from the following angles:
1. When no link is set up between the Client and Server,
Check the log file in gpoc/gpocc on the Client. A "Can't connect to AP server, retry after 5s!" is
normally printed.
Check whether the Server process is started normally. If so, check whether the computer number and IP
address of the Server in $OMCHOME\conf\syscfg.ini are correct.
2. When a link is properly set up between the Client and Server,
Check the log file in gpoc/gpocc on the Client. An "AP server 131 connection (12, 13) established!" is
normally printed.
Enter the user name and password. The user name or password is incorrect if the system displays a
"Logging on to the system failed. Please retry." message. Enter your right user name and password.
41
2.2.6 Main Window Having No Background
 Symptom
The main window had no background.
Check whether there are .bmp files like MainABkGd.bmp, MainABkGd1.bmp, MainABkGd2.bmp, and
MainABkGd3.bmp in $OMCHOME/sourcec.
42
2.2.7 Failure in Retrieving topo Tree
 Symptom
Retrieving the topology tree failed.
1. Check whether FTP_USERNAME and FTP_PASSWORD in [FTPINFO] in lmfcfg.ini on the Server
are correct (you shall have the root right to query the file). If so, make a ftp test of them. If no, correct
them and make a ftp test of them.
2. Check whether the home directory of the ftp user is $OMCHOME/tmp/ftp if the fault cannot be
recovered through the previous step.
$cat /etc/passwd
For example, the information may be displayed as follows (the ftp user name is "ftp"):
...
omc:x:1001:101::/export/home/omc ftp:x:1002:102::/export/home/omc/tmp/ftp
...
The home directory of the ftp user is /export/home/omc/tmp/ftp.
Check the environment variable OMCHOME in sh as follows:
43
$env | grep OMCHOME

OMCHOME=/export/home/omc
The OMCHOME directory is /export/home/omc; therefore, the ftp directory is
/export/home/omc/tmp/ftp. Correct the home directory of the ftp user in /etc/passwd (you shall have the
root right to correct the directory).
3. Check whether the omc user has the right to write in $OMCHOME/tmp/ftp if the fault cannot be
recovered through the previous steps.
$cd $OMCHOME/tmp
$ls -la
total 6
drwxr-xr-x 3 omc omc20 512 Sep 18 13:52 .
drwxr-xr-x 7 omc omc20 512 Sep 20 11:33 ..
drwxr-xr-x 2 omc omc20 512 Aug 16 15:36 ftp
$
The previous information indicates the omc user has the right to read/write in/execute (rwx) the ftp
directory. See the note of the operating system for more details. Correct the right to the directory (you
shall have the root right to correct the right) if the information displayed is not like the previous.
44
4. Check whether there is maintopo.txt in $OMCHOME/ftpc on the Client if the fault cannot be
recovered through the previous steps. If so, delete the file. The environment OMCHOME on a Client is
different from that on the Server. You can query it under Start→Settings→Control
Panel→System→System Variables.
Suppose OMCHOME is E:\OMC-R2.0\Client. Check whether there is E:\OMC-
R2.0\Client\ftpc\maintopo.txt on the Client. If so, delete the file.
Delete the file from OMCHOME/ftpc/*client and then make the check if you fail to retrieve the topo
tree in another application window like Radio Resource Management.
5. Check whether the host hard disk of the Client has enough space if the fault cannot be recovered
through the previous steps.
45
2.2.8 Failure in Refreshing topo Tree

 Symptom
The system displayed a "Refreshing the topo tree failed" message when you refreshed the topology tree
in the main window or another application window during the Client operation.
The cause of the fault is normally that the Server topm process is busy. Wait a minute and retry.
46
2.2.9 Signaling Traced in Illegible Code

 Symptom
The signaling messages traced were displayed in illegible codes on a Client.
 Analysis
The cause of the fault may be that there is zxglang.dll in the system directory. The file zxglang.dll is
copied to the system directory during the data probe installation. The Client prefers to invoke zxglang.dll
in the system directory. The DLL used for signaling tracing on the Client has the same name as the file
zxglang.dll. However, they have different contents.
 Troubleshooting
Delete zxglang.dll from the system directory.
47
2.2.10 Failure in Connecting DIF with Database
 Symptom
A DIF could not be connected with a database.
Cause 1: The database user name, password or service name is inconsistent with the settings in
dbcfg.ini.
Handling: Correct the user name and password.
Cause 2: Software databases running in the background are not of a consistent version.
Handling: Check the r_dbver version. Run dbver.sql under sqlplus. Correct the version name.
Correct "160" in insert into r_dbver(dbver) values('160') in vi /export/home/omc/dbsql/dbver.sql to be
the same as DBVERSION=integ05d-553 in dbcfg.ini. Start sqlplus through cd export/home/omc/dbsql
sqlplus omc/omc. Run @dbver.sql.
48
2.2.11 Failure in Link Setup Between Client and Server
 Symptom
No link could be set up between a Client and Server
Cause 1: The IP address of the Server is not correct in the configuration file syscfg.ini on the Client.
The GPO on the Client stops.
Handling: Modify the corresponding IP address or computer number of the Server in syscfg.ini.
Cause 2: The computer number of the Server is not correct in the configuration file syscfg.ini on the
Client. There has been a link between a Client with the same computer number and the Server.
Handling: Modify the computer number of the Client.
Cause 3: An environment variable on the Client are not correct.
Handling: Modify the environment variable on the Client.
49
2.2.12 Client FTP Failure
 Symptom
The FTP failed on a Client.
 Analysis
The cause of the fault is incorrect FTP configuration.
 Troubleshooting
1. Start the FTP Client on NT.
2. Check the FTP user name and password in lmfcfg.ini are consistent with those set in UNIX.
50
2.2.13 Failure in Link Setup Between MPCOMM and Foreground
 Symptom
No link could be set up between a MPCOMM and foreground.
 Analysis
The cause of the fault is that the foreground has not been started and cannot be reached through the ping
command and that the configuration files do not match.
The BSCID cannot be wrong. Otherwise, the message will indicate an exception although the link is
successfully set up between the MPCOMM and foreground.
51
2.2.14 Error in Initial Version Re-installation
 Symptom
An error occurred when you re-installed an initial version.
The initial version of an OMCR (V2) can be installed only once. You can reconfigure the initial version
rather than re-install it.
52
2.2.15 Client Exception after Link Interruption and Recovery Between

Foreground and Background
 Symptom
A link between a Client and Server interrupted and then recovered like Server process re-startup and
recovery from network interruption. However, the Client could not work normally. For example, it could
not receiver broadcast messages and failed to send a message.
Exit the Client and restart.
53
2.2.16 Alarm Not Reported after Manually Cleared
 Symptom
An alarm could not be reported normally after it was manually cleared in the background.
Synchronize the alarm or switch over the active/standby MPs in the background.
54
2.2.17 Error in OMCR Backup Import
 Symptom
An error occurred when you imported the backup data of an OMCR.
 Analysis
An import will fail when the tables are not deleted from the database before the import.
A database exception will occur during data modification if the moinfo is not arranged after the data
restoration.
 Troubleshooting
Perform the following:
1. Delete the current configuration data.
2. Configure the database table import script.
3. Alter the moinfo related database sequence through altermoinfo.sql after the configuration data is
restored.
55
2.2.18 Error in OMCR Installation
 Symptom
An error occurred when you ran setup.sql during the installation of an OMCR.
The cause of the fault is that the file define.sql in /export/home/omc/sql has not been modified. Modify
the file and then start the installation.
56
2.2.19 Failure in Sending Big Transaction due to BTS Modification
 Symptom
A "submitting big transaction failed" alarm was reported when the data of a BTS was modified.
Block a BTS in the dynamic data management system before modifying its data. Otherwise, a "
submitting big transaction failed" will be reported when a channel is required.
57
2.2.20 Log Query Timeout
 Symptom
Querying a log timed out.
It takes a relatively long time to query a log with many (over 2,000) records. Sometimes the query may
fail due to timeout. You can query the log by strict filtering conditions.
Check whether the Server processes lmf and diffs are normal if the query of a log with few records
timed out.
58
2.2.21 Log Query Failure
 Symptom
Querying a log failed.
The log querying conditions are case sensitive. Be sure to set the querying conditions in proper case.
Otherwise, a query failure will be returned.
59
2.2.22 Virus Problem
 Symptom
All processes were exceptional although the DLL and processes were correct.
There may be a virus in the processes. Run a virus killer and retry.
60
Chapter 3 Service Troubleshooting
3.1 Difficult to Make Call
 Symptom
It was difficult to make an incoming or outgoing call. Many SDCCHs were occupied while few TCHs
were occupied. Some cell data had been modified on the MSC (manufactured by Huawei). The
engineers removed the cell of whose data had been modified and found the fault recovered. They made a
test and found many ASSIGN REQ messages were not returned. The cause of the fault could not be
determined.
 Analysis
Increasing A-interface pages appeared when a cell was added to the MSC from Huawei. The paging on
the A-interface disappeared and the fault recovered when the cell was removed from the Huawei MSC.
It was said the cell supported calls before it was added to the MSC. The engineers determine the cause
of the fault at the Huawei MSC.
 Troubleshooting
61
1. Add location areas. This brings a lot of work. However, the fault can be recovered.
2. Do not multiplex the LAPDs of the BCCH carrier frequency. This can hardly handle the fault. There
are few messages on the TCH carrier frequency. Most physical bandwidth is actually assigned to the
LAPDs of the BCCH carrier frequency.
3. Avoid flourish of messages on the Abis interfaces such as simultaneous short messages in a large area.
62
3.2 Monolog due to Trunk Blocking
 Symptom
Monolog occurred to some BTSs. The office party blocked the channels of the four worst BTSs.
 Analysis
One of the following can cause the fault:
 EDRT hardware problem
 Network planning problem
 A-interface interconnection problem
1. The engineers viewed the A-interface. They found some timeslots were blocked. They checked four
PCMs at the time. The timeslots 17, 18, 19, 20, and 21 of PCM 1, the timeslots 8, 9, 10, 11, 12, 29, 30,
and 31 of PCM 2, the timeslots 1, 2, 20, 21, 22, 23, and 24 of PCM 3 and the timeslots 10, 11, 12, 13,
and 14 of PCM 4 were blocked. The other timeslots of the four PCMs were normal. The engineers
unblocked the timeslots repeatedly. However, the fault did not recover.
2. The engineers unblocked the A-interface PCMs in the dynamic data management system. However,
the fault did not recover.
63
3. The engineers reset the DTI boards one by one. They also reset the EDRT and AIPP boards.
4. The engineers made dialing tests on the site. They blocked the timeslots of the BCCH carrier
frequency of another system for the tests. They blocked the timeslots 1 and 2 first. They blocked the
timeslots 3, 4, 5, 6, 7, and 8 after signaling tracing. They recorded the signaling during the tests. They
then turned off some carrier frequencies to isolate the cause of the fault.
5. The engineers detected interference later. They modified the BCCH carrier frequency and TCH carrier
frequency. However, they found the fault still existed through dialing tests.
6. The engineers of the lower-level BTS then made dialing tests under a BTS with good signals. They
found no TCH was assigned through signaling tracing. They check the A-interface and found all trunks
were blocked. They unblocked the trunks and reset the MP. The system started normally.
7. The engineers found a self-loop was made of PCM 10 on the DDF. They preliminarily determined the
cause of the monolog and subsequent problems.
Finally, the engineers found three of the 16 pairs of PCM cables were wrongly installed on the A-
interface.
 Troubleshooting
Correct the cable connections.
64
3.3 Traffic Overload
 Symptom
A cell met with traffic overload although the traffic per line in the cell was only 0.26 Erl (the
number of TCHs was configured as 29 and the number of TCHs on busy hours was configured as 15).
 Analysis
The assignment failure due to A-interface circuit problem is also regarded as a kind of traffic overload in
BSC performance statistics. Therefore, overload may occur even when there are idle radio channels in a
cell.
The MSC utilized the dual seizure strategy 2 for circuit assignment. According to the strategy, the fault
occurs when the traffic per A-interface timeslot reaches 0.5 Erl. There were 40 E1's under one BSC and
28 E1's under another (traffic per timeslot was about 0.5 Erl on busy hours). Therefore, the fault could
occur although the traffic loads of the two BSCs approximate.
According to specifications, a MSC should release an A-interface circuit when it receives a Clear
Complete message from the BSC. This can avoid the fault. The dual seizure strategy of a MSC can not
only cause the fault but affect the call completion rate of the MSC.
65
3.4 Call Exception after BCC Modification
 Symptom
A test MS could display BTS frequency but could not gain access to the network after BCC was
modified.
 Analysis
The cause of the fault may be that the TSC is not modified to be the same as the BCC in the BCCH of
the carrier frequency after BCC is modified under radio resources→cell attributes.
 Troubleshooting
Modify the TSC to be the same as the BCC.
66
3.5 Failure in Network Access under Normal New BTS
 Symptom
A new BTS could not gain access to the network although it was in the normal state.
The cause of the fault may be that the CIs of the new cells are not added to the MSC. The CI of a new
cell shall be added to the MSC. Otherwise, MSs will not make calls although they can receive signals.
67
3.6 Call Dropped
 Symptom
A call was dropped.
 Analysis
The cause of the fault may be that the inactive Tiar/Tias SCCP timer on the A-interface does not match
the corresponding setting on the MSC.
 Troubleshooting
Check whether the Tiar/Tias SCCP timer matches the corresponding setting on the MSC. You can learn
the setting on the MSC through signaling tracing.
68
3.7 Call Exception after BCCH Carrier Frequency Change
 Symptom
No conversation could be made normally after a BCCH carrier frequency was changed.
 Analysis
The cause of the fault may be the incomplete switchover procedure between a non-BCCH carrier
frequency and BCCH carrier frequency in the radio resources system. The incomplete procedure may
cause an error in the logical data relationship and call exception.
 Troubleshooting
The complete carrier frequencies switchover procedure is as follows:
1. Record the frequency of either carrier frequency and the combination mode of each channel.
2. Modify the frequency of either carrier frequency (you need not modify the frequency information in
the cell because the two frequencies need only be interchanged).
3. Change the channel combination modes at one carrier frequency with those at the other.
4. Block/unblock the two carrier frequencies and cells.
The procedure is relatively complicated. You should implement the switchover in an integrated
69
configuration environment.
70
Chapter 4 Maintenance Experience
4.1 Periodic View of Foreground Printed Files
Check periodically whether there is any new ERROR.LOG, INT13.LOG, or POWERON.LOG in the
trace directory on the active/standby MPs of the foreground modules to find a hidden fault as early as
possible. Please send the files, if any, immediately to ZTE CORPORATION.
Delete the files from the MPs after the check lest the files should become very big.
Note: Get the files through OMCFTP at low traffic time.
71
4.2 Block and Unblock before Timeslot/Channel Combination
Implement the block and unblock procedures when you modify a timeslot/channel combination.
Otherwise, there will appear data inconsistency between CHP, MP, and OMU. The data
inconsistency is very difficult to recover.
72
4.3 Making Log File Print Unavailable
Do not print log files on the Server and Clients in the OMCR. The system will not exit when omccron is
not configured as periodic log clearing.
To make log file print unavailable on the Server and Clients, configure trace in [SYSCFG] in syscfg.ini
in the conf directory on the Server and Clients to zero.
For example,
[SYSCFG]
Trace =0
TracePrint = 0
TraceMode = 2
TracePath =
TraceLev = 1
......
73
4.4 Handling A-Interface Circuit Status Exception – Not Mounted on

MSC
 Symptom
The status of some or all trunk circuits in the R_ATRUNK table was 000000000004 (not mounted on
MSC) when the active and standby MPs on the central module were reset or powered off
simultaneously. However, the signaling circuits were normal. All the circuits were found normal on the
MSC (manufactured by Nortel).
 Analysis
There are block and unblock procedures of the A-interface circuits when the active and standby MPs on
the central module are reset simultaneously. It takes a relatively long time to complete the procedures if
there are many circuits on the A-interface. The SS7 links may find some or all circuits in the blocked
state when they come into service and reset. The BSC will send a "circuit group block" message to the
MSC in this case. The MSC will then return a "circuit group block acknowledgement" message (with
null circuit ID) and "circuit not mounted" message to the BSC. The BSC will record some or all A-
interface circuits as not mounted on the MSC.
74
 Troubleshooting
Method 1: Implement circuit assembly of the PCM cables in the dynamic data management system
(recommended).
Method 2: Remove the related STB to disable the whole SS7 links before resetting the active and
standby MPs on the central module. Check that the status of all trunk circuits in the R_ATRUNK table is
0 when the trunk block and unblock procedures complete on the A-interface. Insert the STB to enable
the whole SS7 links. The BSC will not send a "circuit group block" message to the MSC because the A-
interface trunk circuits have turned to the normal state. The A-interface trunk circuits will recover to the
normal state on the BSC side.
Note: To restart a BSC interconnected with a Nortel MSC, follow the method 2, risking the problem.
75
4.5 Matters to Attention of BSC with EDRTs
The DSP chips on an EDRT are sensitive to clock signals. The DSP chips may become exceptional and
cause bidiretional silence due to clock interference. Observe the following for a BSC with EDRTs:
1. Do not remove and insert the standby SYCK, standby DSNI (normally in slot 21 or 22) connected
with TCPP and standby TCPP during the operation. The reset of a standby board in the background has
no impact.
2. If required, remove and insert any of the previous board at low traffic time (for example, at midnight).
Reset the concerned EDRTs one by one after the removal and insertion.
76
Appendix A Board and Component Replacement
1. Overview of Board and Component Replacement
Replacement of a faulty board or component is very useful and important in the routine maintenance.
The maintenance personnel should contact the related technical personnel or ZTE local office for the
related technical support and guide.
Observe the following for board replacement:
1) Pack spare parts in good conditions in antistatic bags (with anti-humidity bag). Classify and save
them properly in cartons. Attach a type label to each antistatic bag or carton to facilitate your immediate
recognition.
2) Wear an antistatic wrist strap when you insert or remove a board. Do not touch the circuits, elements,
or chutes on a board when you handle the board. Do not insert or remove a board with excess force,
risking distortion of a pin or chute on the board or backplane.
3) Mark fault causes on the faulty boards replaced before you pack them in antistatic bags, classify and
save them properly.
4) Install a standard blank panel in an empty slot after you remove a faulty board from the slot and have
77
no spare board to insert. This is for the dustproof and decorative purposes.
5) Make sure a board is completely seated in its slot.
6) Do not hot insert or remove a power supply board or MP.
78
2. Common Board Replacement
1) Preparation for replacement
 Determine a board is faulty and need be replaced through fault analysis.
 Determine a spare board is in good conditions and of a consistent type with the faulty board.
 Prepare an antistatic bag, anti-humidity bag, classified carton and some mark labels.
2) Replacement procedure
a) Wear an antistatic wrist strap.
b) To replace an active board, switch over the active/standby boards and make the previous standby
board active.
c) Remove the faulty board from the slot. Pull the ejector lever on the faulty board downward using one
hand to eject the board from the slot. Hold the bottom edge of the board in the other hand and pull it out
gently. Do not touch the elements and circuits on the board.
d) Pack the faulty board in the antistatic bag with anti-humidity bag. Attach a label to the antistatic bag
with the board type, slot, program version and "FAULTY". Save the faulty board in the classified carton.
Attach a label to the carton to facilitate your immediate recognition.
e) Insert the spare board in the corresponding slot. Push the ejector lever on the board and insert the
board with appropriate force until the ejector lever is in the locked position. The board is fully seated in
79
the slot.
f) Switch over the active/standby boards and make the new board active if the faulty board replaced was
in the active state before the replacement.
3) Confirmation after replacement
The new board implements a self-check after you insert it. Its indicators will be normal and the services
will recover when it passes the self-check. This indicates the replacement is a success. See Chapter 3 in
this manual for indicator detection. The replacement fails when the board implements the self-check
continuously or displays an exception and does not pass the self-check. The corresponding services will
not recover in this case. Check whether the spare board is damaged. The cause of the fault may not lie
with the board. You can observe the foreground and background alarms to isolate the cause of the fault.
80
3. Component Replacement
A component here refers to a frame or backplane. You have to get the consent of the office party and
corresponding technical personnel before you replace a component.
1) Preparation for replacement
Refer to Section A.2 in this manual.
2) Procedure of frame and backplane replacement
a) Wear an antistatic wrist strap and disconnect the equipment from power supply.
b) Record the boards and corresponding slots on the shelf. Remove all the boards from their slots.
c) Record the connection positions of the cables. Remove all the cables including all 3  8 cables and 6-
core power cables on either side from the backplane.
d) Remove the front door from the rack and place it gently.
e) Loosen the four screws that tighten the shelf. Pull out the frame.
f) Remove the screws and remove the backplane.
g) Install the new backplane on the empty frame (or insert the backplane on the new frame). Do not put
the upside down.
h) Install mini jumpers (with RS485 addresses) on the left and right sides of the new backplane with
reference to the previous backplane. Install cable lock plates if there are no 3  8 cable lock plates on the
81
96-core socket in the new backplane. Install them with reference to the previous backplane.
i) Insert the frame with the backplane in the rack.
j) Install the front door.
k) Install the power cables and backplane cables according to your record. Pay attention to the
installation direction of the 3  8 cables. The lock plate can be locked only when they are inserted in one
direction. The 6-core power cables can also be inserted in one direction.
l) Insert the boards in the corresponding slots according to your record. Do not touch the elements and
circuits on the boards.
m) Check that the cables and boards are properly installed.
Note: The MP boards apply the –48 V power supply. A board will be damaged when you insert it in a
MP slot.
n) Power on the rack. The system starts.
3) Confirmation after replacement
The MPs start and the board versions are loaded when you power on the system. There is a self-check
procedure before the board versions come into operation. The board indicators will be normal and the
services will recover when the self-check is passed. This indicates the replacement is a success. See
Chapter 3 in this manual for indicator detection. The replacement fails when the boards implement the
82
self-check continuously or display exceptions and do not pass the self-check. The corresponding
services will not recover in this case. Check whether the spare component is damaged. The cause of the
fault may not lie with the frame. You can observe the foreground and background alarms to isolate the
cause of the fault.
83
Appendix B ZXG10.CFG
The file ZXG10.CFG needs no modification normally. The system will adopt the following default
parameter settings when the file does not exist.
Variable Description Remark

Indicates whether to monitor the
The trap information is to be saved in
TICK TRAP length of time of process operation.
\TRACE\MSGTRAP.LOG.
Default: 0
Related to the previous variable. Tick
limit cannot be less than 2. Otherwise,
Trap threshold of process operation.
TICK LIMIT the system will break down and reset
Default: 20
immediately due to too frequent file
writing events.
TRAP MSG Maximum length of a message to be The extension of the message beyond
LEN trapped. Default: 100 the threshold will be cut.
85
The bits 0~7 indicate the scheduling
TRAP TASK Monitor task bitmap. Default: 0XFF
tasks 1~8.
The useful information can be recorded
Indicates whether to save the system
in \TRACE\POWERON.LOG when the
REG SMEM operation information in SMEM.
system information is saved in SMEM.
Default: 1
Otherwise, the record is invalid.
RESET ON Indicates whether to reset MP in case The error here refers to an endless loop
ERROR of an error. Default: 0 or over-frequent operation.
The CPU full-load running threshold can
enhance the anti-impact capability of the
RESET TIMES Number of overload events at which
system. However, the system will reset
LIMIT MP is reset. Default: 3
directly regardless of the count when it
detects an endless loop.
PROC MANY ManyRun trap threshold of
RUN scheduling process. Default: 8000
86

TASK MANY ManyRun trap threshold of external
RUN task. Default: 10000
OPEN TRACE
Process trace flag. Default: 0 It can control the process monitor.
FLAG
If this variable is enabled, the central
A global flag which indicates whether module can forward the TCP
TCP ROUTE TCP communication can be communication when the TCP
forwarded. Default: 0 communication of a peripheral module is
interrupted.
Signaling error print controller.
SPS PRINT It controls the error print frequency.
Default: 0
PRINT Error print and saving controller.
ERROR Default: 1
MEAS Performance measurement version.
VERSION Default: 0
87

LAPD flow control threshold to stop The recovery procedure starts
LAPD CUT
board cut. Default: 95 immediately after the cut is stopped.
LAPD LAPD flow control recovery
RECOVER threshold. Default: 70
Load threshold of flow control
CSCPU LIMIT It indicates the load occupied by task 2.
service. Default: 80
CPU ALARM CPU alarm threshold. Default: 70
Indicates whether a load alarm is to
ALARM MSC
be reported to MSC. Default: FALSE
88
Appendix C TCPIP.CFG
Variable Host Field Description
BSC ID. The foreground is insensitive to the variable. The OMCR
BscID [MAIN]
manages the BSCs through BSC IDs. It a non-zero byte value.
IsRemote [MAIN] Indicates whether the module is remote. It is 0 or 1.
Port through which the local MP receives a link setup request from
TcpPort [MAIN]
TCP. It is normally 5000.
UdpPort [MAIN] UDP communication port in the local MP. It is normally 5001.
Foreground/background TCP communication network adapter of
TcpCard [MAIN]
the local MP. It is normally 1.
UDP communication network adapter of the local MP. It is
UdpCard [MAIN]
normally 0.
Udp SubNet [MAIN] It has to be 14 currently. GDPP: 138.14.composit unit number.unit
number
89
MP: 138.14. 129.
Computer number of the Server. Multiple (up to two presently)
Server Mno [SERVER] Servers can be configured. The number of Servers is defined in
SYSCFG.H.
IP address of the Server. It has one-to-one correspondence with the
Server IP [SERVER] Server computer number. It shall not be identical to any of the
following addresses.
IP address of the test Server. It shall not be identical to the Server
Test IP [SERVER]
IP address or any LMT address.
LMT Mno [LMT] Computer number of the LMT
LMT IP [LMT] IP address of the LMT
MP module number. The MP IP address will be read when the local
MP has the module number.
Module [MODULE]
1 indicates the central module (switch module). 2~9 indicate the
peripheral modules.
90

Left IP [MODULE] MP is at the left IP address.
Right IP [MODULE] MP is at the right IP address.
91

01 ZXG10 BSC Troubleshooting Manual

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

01 ZXG10 BSC Troubleshooting Manual

Caricato da

Copyright:

Formati disponibili

ZXG10-BSC Troubleshooting Manual

(Manual version 20041010-R1.0)

Chapter 2 Provides the OMCR concerned fault analysis and troubleshooting.

Chapter 3 Provides the service concerned fault analysis and troubleshooting.

Chapter 4 Gives some BSC maintenance experience.

Appendix A Introduces the board and component replacement.

Appendix B Describes the configuration file ZXG10.CFG.

1.1 BSC TROUBLESHOOTING............................................................................................................... 1

CHAPTER 2 OMCR TROUBLESHOOTING......................................................................................... 29

2.1 SERVER TROUBLESHOOTING...........................................................................................................29

CHAPTER 3 SERVICE TROUBLESHOOTING..................................................................................... 61

3.1 DIFFICULT TO MAKE CALL........................................................................................................... 61

4.1 PERIODIC VIEW OF FOREGROUND PRINTED FILES....................................................................... 71

APPENDIX A BOARD AND COMPONENT REPLACEMENT.......................................................... 77

1.1 BSC Troubleshooting

1.1.1 PP Not Setting Up Link

1.1.2 Alarm Indicator on PP Being ON

1.1.3 DSNI Switchover

1.1.4 STB Faulty

1.1.5 All SS7 Links Broken

1.1.6 A-interface Circuit Unassembled and Blocked

1.1.7 BATC Startup Failure

BATC (HW7, HW8)

1.1.8 BSC Startup Failure after T Network Reset

1.1.9 Active/Standby MPs Switchover

1.1.10 MP CPU Overload Alarm

1.1.11 Alarm Indicator on MP Flashing or Being ON

1.1.12 Newly Added Peripheral Module Exceptional

1.1.13 Failure in Sending Data to Foreground after Addition of New BSC

1.2 GPRS Troubleshooting

1.2.1 Interruption on Gb Interface due to Transmission Error

1.2.2 GPRS Transmission Failure due to CRC

1.2.3 NSVC on Gb Interface Faulty

1.2.4 GPRS Service Unavailable

1.2.5 MS Browsing Failure

1.2.6 PS Channel due to Absence of Frame Number

2.1 Server Troubleshooting

2.1.1 Repeated Server Process Startups

2.1.3 Synchronization of Background with Foreground after Recovery from Link

2.1.4 Database –1 Error

2.1.5 Failure in Automatic Oracle Startup

2.1.6 Oracle Client Not Supporting Processing in Chinese

2.2 Client Troubleshooting

2.2.1 Failure in Finding DLL

2.2.2 Process Exception

2.2.3 Failure in Opening Resource File *.res

2.2.4 Failure in Opening Help File

2.2.5 Failure in Logging on to Main Window

2.2.6 Main Window Having No Background

2.2.7 Failure in Retrieving topo Tree

$env | grep OMCHOME

2.2.8 Failure in Refreshing topo Tree

2.2.9 Signaling Traced in Illegible Code

2.2.10 Failure in Connecting DIF with Database

2.2.11 Failure in Link Setup Between Client and Server

2.2.12 Client FTP Failure

2.2.13 Failure in Link Setup Between MPCOMM and Foreground

2.2.14 Error in Initial Version Re-installation

2.2.15 Client Exception after Link Interruption and Recovery Between

2.2.16 Alarm Not Reported after Manually Cleared

2.2.17 Error in OMCR Backup Import

2.2.18 Error in OMCR Installation

2.2.19 Failure in Sending Big Transaction due to BTS Modification

2.2.20 Log Query Timeout