05-ZXG10-BSC Daily Maintenance Instruction Manual

ZXG10-BSC Daily Maintenance
Instruction Manual
(Manual Version 20041010-R1.0)
ZTE CORPORATION
Preface
This manual describes the daily maintenance procedures of BSC, which is especially used for daily
maintenance of BSC. It is intended for daily maintenance personnel of the equipment.
This manual comprises the following four chapters:
Chapter 1 BSC Daily Routine Maintenance
Chapter 2BSC Weekly Routine Maintenance
Chapter 3 BSC Monthly Routine Maintenance
Chapter 4 BSC Half-yearly Routine Maintenance
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.
i
ii
Contents
CHAPTER 1 BSC DAILY ROUTINE MAINTENANCE..................................................... 1
1.1 CHECKING POWER VOLTAGE......................................................................................... 4

1.2 CHECKING EQUIPMENT ROOM TEMPERATURE................................................................ 3
1.3 CHECKING EQUIPMENT HUMIDITY.................................................................................. 4
1.4 CHECKING WHETHER THE FRONT AND BACK DOORS OF THE RACK HAVE BEEN CLOSED
4
1.5 CHECKING NETWORK MANAGEMENT CHANNEL............................................................ 5
1.5.1 Checking Link Setup between the Server and MP.................................................. 5
1.5.2 Checking Link Setup between the Server and Client.............................................. 9
1.6 OBSERVING CURRENT ALARM OF BSC VIA THE OPERATION & MAINTENANCE
BACKGROUND.................................................................................................................. 11
1.7 OBSERVING CURRENT NOTICE OF BSC VIA THE OPERATION & MAINTENANCE
BACKGROUND.................................................................................................................. 11
1.8 OBSERVING PAST 24-HOUR HISTORY ALARMS AND NOTICES OF BSC VIA THE
i
OPERATION & MAINTENANCE BACKGROUND.................................................................... 12
1.9 CREATING BSC’S DAILY PERFORMANCE REPORT VIA THE OPERATION & MAINTENANCE
BACKGROUND.................................................................................................................. 12
1.10 CHECKING BOARD RUNNING STATUS....................................................................... 13
1.10.1 Checking Running Status of the MP Board..................................................... 13
1.10.2Checking Running Status of the SMEM Board.................................................. 16
1.10.3Checking Running Status of the COMM (MPPP/MPMP) Board..................... 18
1.10.4Checking Running Status of the COMM (MTP2) Board................................... 20
1.10.5Checking Running Status of the ECOM (MTP2) Board................................... 22
1.10.6Checking Running Status of the COMM (LAPD) Board................................... 26
1.10.7Checking Running Status of the ECOM (LAPD/MPPP/MPMP) Board.......... 30
1.10.8Checking Running Status of the PEPD (MON) Board....................................... 33
1.10.9Checking Running Status of the PCOM Board.................................................. 36
1.10.10Checking Running Status of the BOSN Board.................................................. 41
1.10.11Checking Running Status of the DSNI/COMI Board....................................... 44
1.10.12Checking Running Status of the CKI Board..................................................... 46
1.10.13Checking Running Status of the SYCK Board.................................................. 51
ii
1.10.14Checking Running Status of the DRT/EDRT Board....................................... 55
1.10.15Checking Running Status of the TIC/DTI Board.............................................. 58
1.10.16Checking Running Status of the GPP Board..................................................... 61
1.10.17Checking Running Status of the PUC Board..................................................... 65
1.10.18Checking Running Status of the BRP Board..................................................... 68
1.10.19Checking Running Status of the FRP Board..................................................... 71
1.10.20Checking Running Status of the GIPP Board.................................................. 74
1.10.21Checking Running Status of the POWB Board.............................................. 76
1.10.22Checking Running Status of the POWP Rack Power Distributor..................... 79
1.10.23Checking Running Status of the SMB Board.................................................. 82
1.10.24Checking Running Status of the TMM Module.............................................. 85
1.10.25Supplementary Description of Indicators......................................................... 89
1.11 CHECKING RUNNING STATUS OF THE BACKGROUND SERVER................................... 90
1.11.1 Viewing Running Status of the Background Server Process with omcps Tool... 90
1.11.2Viewing Process Memory Occupation with TOP Tool....................................... 94
1.12 SERVICE PERFORMANCE CHECK.............................................................................. 99
1.12.1 System Performance Monitoring....................................................................... 99
iii
1.12.2 Monitoring Memory Occupation....................................................................... 102
1.12.3 Monitoring Performance of the Disk System..................................................... 110
1.13 CHECKING WHETHER DATABASE RUNNING IS NORMAL.......................................... 114
1.14 CHECKING WHETHER THE TABLE SPACE OF THE DATABASE IS NORMAL................. 117
1.15 CHECKING SS7 LINK RUNNING STATUS OF THE CENTRAL MODULE........................ 118
1.16 CHECKING RUNNING STATUS OF EACH MODULE’S LAPD LINK................................ 119
1.17 CHECKING FRAME RELAY RUNNING STATUS OF THE GB INTERFACE..................... 121
1.18 DUTY LOG............................................................................................................... 122
CHAPTER 2 WEEKLY ROUTINE MAINTENANCE.................................................. 125
2.1 EQUIPMENT CLEANNESS............................................................................................. 126

2.2 VIEWING BUSY-HOUR MP LOAD.............................................................................. 127
2.3 CHECKING COMMUNICATION BETWEEN MP AND EACH PP UNIT................................ 128
2.4 BACKING UP ZDB OF ALL FOREGROUND MODULES.................................................. 129
2.5 ANALYZING HISTORY ALARMS OF THE PAST WEEK.................................................. 133
2.6 ANALYZING DAILY PERFORMANCE REPORTS OF THE PAST WEEK............................ 134
2.7 DATA BACKUP........................................................................................................... 135
iv
2.7.1 Backing up Configuration Data........................................................................... 135
2.7.2 Backing up Alarm Data...................................................................................... 140
2.7.3 Backing up Performance Data.............................................................................. 142
2.8 ALARM AND PERFORMANCE DATA QUERY................................................................ 145
2.8.1 Alarm Data Query................................................................................................ 145
2.8.2 Performance Data Query...................................................................................... 152
2.9 ALARM AND PERFORMANCE DATA DELETION............................................................ 155
2.9.1 Alarm Data Deletion............................................................................................. 155
2.9.2 Performance Data Deletion.................................................................................. 161
2.10 ANTIVIRUS OF SERVER AND CLIENT COMPUTERS..................................................... 166
2.11 CHECKING TOOL INSTRUMENTS AND DOCUMENTATION.......................................... 168
CHAPTER 3 MONTHLY ROUTINE MAINTENANCE.............................................. 171
3.1 PERFORMING STATISTICS AND ANALYSIS ON ALL HISTORY ALARMS IN THE PAST
MONTH............................................................................................................................. 172
3.2 PERFORMING STATISTICS AND ANALYSIS ON ALL DAILY PERFORMANCE REPORTS IN THE
PAST MONTH.................................................................................................................. 172
v
3.3 SERVICE DIALING TEST............................................................................................. 173
3.3.1 Voice Service Dialing Test.................................................................................. 173
3.3.2 Test on GPRS Service Functions....................................................................... 176
3.4 FETCHING LOG FILES FROM THE FOREGROUND......................................................... 181
3.5 BACKING UP ALARM DATA......................................................................................... 182
3.6 BACKING UP AND DELETING OLD LOGS.................................................................... 183
3.7 PERFORMING SECONDARY BACKUP ON BACKUP DATA OF THIS MONTH FROM THE
SERVER TO OTHER STORAGE MEDIA.............................................................................. 188
3.8 CHECKING WHETHER THE ALARM BOX IS RUNNING NORMALLY............................ 189
3.9 CHECKING SPARE PARTS............................................................................................. 190
3.10 SCANNING VIRUSES FOR THE CLIENT AND SERVER COMPUTERS............................ 192
CHAPTER 4 HALF-YEARLY ROUTINE MAINTENANCE....................................... 193
4.1 ACTIVE/STANDBY BOARD RESET.............................................................................. 194

4.2 ACTIVE/STANDBY BOARD CHANGEOVER.................................................................... 196
4.3 NETWORK QUALITY TEST......................................................................................... 197
4.3.1 BTS Cell Coverage Test...................................................................................... 197
vi
4.3.2 BTS Cell Call Quality Test.................................................................................. 200
4.3.3 Handover Test........................................................................................................ 200
4.4 CABLE CONNECTION.................................................................................................... 201
4.5 GROUNDING CHECK.................................................................................................... 203
4.6 CHECKING SYSTEM CLOCKS OF MP, SERVER AND CLIENT....................................... 204
4.7 CHECKING SOFTWARE VERSION AND DATA CONFIGURATION................................... 206
4.7.1 Checking Software Version.................................................................................. 206
4.7.2 Checking Data Configuration.............................................................................. 209
4.7.3 Performing Secondary Backup on Backup Configuration Data from the Server to
Other Storage Media.................................................................................................... 211
4.7.4 Deleting All Backup Data from the Server......................................................... 212
4.7.5 Backing up Several Major Foreground Files..................................................... 213
4.7.6 Checking Running Status of the Power Equipment.............................................. 214
4.7.7 Checking Running Status of the Transmission Equipment................................ 215
4.7.8 Checking Running Status of the Battery............................................................ 215
Appendix Summary List of BSC Maintenance Items......................................................... 217
vii
viii

The daily routine maintenance items of the BSC equipment are shown in the following table:
Item Classification Check Item Remarks

Please refer to
Checking power voltage
Section 1.1.
Please refer to
Checking equipment room temperature
Environment monitoring Section 1.2.
maintenance check Please refer to
Checking equipment room humidity
Section 1.3.
Checking whether the front and back doors of Please refer to
the rack have been closed Section 1.4.
Please refer to
Checking network management channel
Section 1.5.
Please refer to
Observing current alarm of BSC via the Section Error:
Main equipment running
status maintenance check operation & maintenance background Reference source
not found.
Observing current notice of BSC via the Please refer to
operation & maintenance background Section 1.7.
1
ZXG10-BSC Daily Maintenance Instruction Manual

Observing past 24-hour history alarms of BSC Please refer to
via the operation & maintenance background Section 1.8.
Creating BSC’s daily performance report via the Please refer to
Please refer to
Checking board running status
Section 1.10.
Checking running status of the background Please refer to
service process Section 1.11.
Server maintenance check
Please refer to
Checking server performance
Section 1.12.
Checking whether the database running is Please refer to
Database maintenance normal Section 1.13.
check Checking whether the table space and index Please refer to
space of the database are normal Section 1.14.
Interface running status Checking SS7 link running status of the central Please refer to
maintenance check module Section 1.15.
Checking LapD link running status of each Please refer to
module Section 1.16.
2

Please refer to
Checking frame relay status of the Gb interface
Section 1.17.
Please refer to
Other maintenance items Duty record
Section 1.18.
1.1 Checking Power Voltage
[Maintenance tool] Check whether there is any P power undervoltage alarm with the alarm management
function of the OMCR (V2) client.
[Test procedure]
1. Log in to the OMCR (V2) client.
2. Enter the alarm management interface.
3. Check whether there is any P power undervoltage alarm on the current alarm display interface.
[Normal result] There is no P power undervoltage alarm on the current alarm display interface.
[Troubleshooting] If there is any P power undervoltage alarm on the alarm management interface, please
refer to the part related to power equipment alarms in ZXG10-BSC (V2) Base Station Controller
Maintenance Manual for handling.
3
1.2 Checking Equipment Room Temperature
[Maintenance tool] None.

[Test procedure] Observe the temperature recorded in the thermometer within the equipment room.
[Normal result] 15C~30C (long-term).
[Troubleshooting] Check whether the air conditioning system is running normally and whether the status
setting is correct.
1.3 Checking Equipment Humidity

[Test procedure] Observe the humidity recorded in the hygrometer within the equipment room.
[Normal result] Relative humidity: 40%~65% (long-term)
[Troubleshooting] A humidifier is recommended if the humidity in the equipment room is too low.
1.4 Checking Whether the Front and Back Doors of the Rack Have
Been Closed
4
[Test procedure] Check whether the front and back doors of the rack have been closed.
[Normal result] Both the front and back doors are close.
[Troubleshooting] Please close any open front or back door of the rack in time.
1.5 Checking Network Management Channel
1.5.1 Checking Link Setup between the Server and MP

[Maintenance tool]
Run “mpinfo” in the application server console while ensuring that both the MP running and the
network connection is normal.
The function of the “mpinfo” command is to check the communication between the OMCR (V2) server
and BSC (V2) MP.
[Test procedure]
Run the “mpinfo” command in the application server console. A command example is as follows:
bash-2.02$ mpinfo
5
BSC MP MDU Link LinkTime InBytes InRate TIRate OutBytes OutRate TORate
1 L 209846 178219738 1536 849 36454044 316 173
1 R 417401 5347616 0 12 6215712 32 14
2 L 417401 5347168 0 12 6215280 0 14
2 R 417401 56515404 0 135 9872126 0 23
3 L 417401 55285002 0 132 11305780 0 27
3 R 417401 5347104 0 12 6215280 0 14
4 L 170026 23812584 458 140 4900862 32 28
4 R 417401 5347296 0 12 6215280 32 14
5 L 123 7032786 64 185 1549705 32 40
5 R 417401 5347360 0 12 6215280 32 14
 Tips: The items displayed on the columns include the BSC No., module No., left/right MP
(represented with L and R respectively), whether to set up a link (L: Link setup; U: Broken
link), link setup time (unit: second) and so on.
[Normal result]
6
The left and right MPs of all modules in all BSCs have been connected with the OMCR (V2) server.
If the link between the server and an MP is normal, the link indication (Link) on the MP will be “L”.
If the link between the server and MP is broken, the link indication on the corresponding link will be
“U”. In the meantime, you can judge whether the MP link has been broken based on the link time
(LinkTime).
In the above example, by observing the link time (LinkTime), we can see that the link of the left MP in
module 5 of BSC 1 has just been broken but recovered about 2 minutes 123 seconds) ago.
[Troubleshooting]
If no left/right MP has been connected with the OMCR (V2) server in all modules of all BSCs, please
check the failure cause in the following sequence:
1. Check whether both the configuration of the server configuration file (bsccfg.ini) and that of the
MP configuration file (tcpip.cfg) are correct.
2. Check the current network connection quality between the server and MP. For example, you can
ping the sever and MP to check the physical connection of the network.
3. If you are sure that there is no error in the configuration files and the network quality is sound,
please contact the local ZTE office.
[Precautions]
You can judge whether an MP is running normally via the indicators on this MP. It is in the normal status
7
if the RUN indicator flashes in a frequency of 1Hz and the alarm indicator is off.
1.5.2 Checking Link Setup between the Server and Client

[Maintenance tool]
Check it by starting the client and running each application module while ensuring that both the server
software running and the network connection are normal.
[Test procedure]
1. Double-click on the client applications; input the user name and password; select the login network
management domain; and then click <OK> to log in to the client.
2. After successful login, enter the client main interface to check whether each application window
can be opened.
[Normal result]
1. The client can be successfully started.
2. Each application window of the client main interface can be normally opened.
[Troubleshooting]
1. If a failure message is returned for client login, please check the failure cause in the following
sequence:
1) Check whether the input user name, password and network management domain are correct.
8
2) Check the current network connection quality between the client and server. For example, you
can ping the server to see whether it is connected or input “telnet 138.1.1.1” (provided that the
server’s IP address is 138.1.1.1) into the Windows running input box (or under the dos
prompter). Then, input the user name and password as prompted and check whether you can log
in to the server.
3) Check whether the configuration of the client configuration file (syscfg.ini) is consistent with
that of the server configuration file (syscfg.ini). For example, you can check whether the server’s
machine No. and IP address are consistent in these two configuration files.
2. If any abnormal alert box pops up when you enter the client main interface and open each
application window, please operate according to the error cause prompt. If an abnormal window
pops up but there is no failure cause prompt, please contact the local ZTE office.
1.6 Observing Current Alarm of BSC via the Operation & Maintenance
Background
[Maintenance tool] View the current alarm with the alarm management function of the OMCR (V2)
client.
9
[Test procedure] Please refer to ZXG10- BSS (V2) Base Station Subsystem Operation Manual.
[Normal result] No current alarm of the related BSC is displayed on the alarm management logic view.
[Troubleshooting] If the current alarms of the BSC are available at the operation & maintenance
background, please handle the related alarms.
1.7 Observing Current Notice of BSC via the Operation & Maintenance
Background
[Maintenance tool] View a BSC’s current notification messages with the alarm management function of
the OMCR (V2) client.
[Test procedure] Please refer to ZXG10-BSS (V2) Base Station Subsystem Operation Manual.
[Normal result] No notification message of this BSC is displayed on the query result display interface.
[Troubleshooting] If the current notice messages of the BSC are available at the operation &
maintenance background, please handle them by referring to related notices.
1.8 Observing Past 24-hour History Alarms and Notices of BSC via the
Operation & Maintenance Background
[Maintenance tool] Query history alarms (alarms at Level 1 and 2 in the past 24 hours of a BSC with the
10
alarm management function of the OMCR (V2) client.
[Normal result] History alarm display is available on the alarm management interface.
[Troubleshooting] Please focus on analysis and handling of any frequently occurring alarms in the
history alarms of the past 24 hours at the operation & maintenance background.
1.9 Creating BSC’s Daily Performance Report via the Operation &
Maintenance Background
[Maintenance tool] Create a daily performance report via the performance management part of the
OMCR (V2) client.
[Normal result] A daily report can be generated and every index is normal.
[Troubleshooting] Handle alarms based on the abnormal indexes in the daily performance report.
11
1.10 Checking Board Running Status
1.10.1
Checking Running Status of the MP Board
[Maintenance tool] Observe alarms at the operation & maintenance background and the panel indicators
of an MP board to judge its running status.
[Test procedure]
1. In the alarm management part of the OMCR (V2) client, check whether there is any current
alarm from the MP board.
2. Observe the panel indicators of the MP board and judge its running status according to whether
the panel indicators are normal or abnormal.
[Normal result]
1. No current alarm is detected for the MP board via the alarm management part of the OMCR (V2)
client.
2. The normal status of indicators on an MP board is shown in the following table:
Category Board Location Name Description Meaning Work Mode
12
HL Green Running Flashing slowly during
1
1 indicator status normal running
Control HL Green Constantly on when the
layer MP board 3 Active
3 indicator board is active
board
HL Green Constantly on when the
4 Standby
4 indicator board is standby
Note: Quick flashing of indicators is defined as on/off 5 times per second, that is, the on/off time is
100ms respectively. Slow flashing of indicators is defined as on/off 1 time per second, that is, the on/off
time is 500ms respectively. Unless otherwise specified, the indicators and switches on the panel are
arranged in the order of 1, 2, 3, … successively from the top down.
[Troubleshooting]
The abnormal status of indicators on an MP board is shown in the following table:
Control Red Board Constantly on when the
layer MP board 2 HL2
indicator failure board fails
board
13
1.10.2Checking Running Status of the SMEM Board
[Maintenance tool]
Observe alarms at the operation & maintenance background and the panel indicators of a SMEM board
to judge its running status.
[Test procedure]
1. In the alarm management part of the OMCR (V2) client, check whether there is any current alarm
from the SMEM board.
2. Observe the panel indicators of the SMEM board and judge its running status according to whether
[Normal result]
1. No current alarm is detected for the SMEM board via the alarm management part of the OMCR (V2)
client.
2. The normal status of indicators on an SMEM board is shown in the following table:

Control SMEM HL Green Runnin Flashing slowly during
1 normal running
layer board board 1 indicator g status
[Troubleshooting]
14
The abnormal status of indicators on an SMEM board is shown in the following table:

Control SMEM HL Red Board On when the board
2
layer board board 2 indicator failure fails
1.10.3 Checking Running Status of the COMM (MPPP/MPMP) Board
[Maintenance tool]
Observe alarms at the operation & maintenance background and the panel indicators of a COMM
(MPPP/MPMP) board to judge its running status.
[Test procedure]
from the COMM (MPPP/MPMP) board.
2. Observe the panel indicators of the COMM (MPPP/MPMP) board and judge its running status
according to whether the panel indicators are normal or abnormal.
[Normal result]
1. No current alarm is detected for the COMM (MPPP/MPMP) board via the alarm management part of
the OMCR (V2) client.
15
2. The normal status of indicators on a COMM (MPPP/MPMP) board is shown in the following table:

HL Green Running Flashing slowly:
Control 1
COMM board 1 indicator status Running normally
layer
(MPPP/MPMP) HL Red Board Off: Running
board 2
2 indicator failure normally
[Troubleshooting]
The abnormal status of indicators on a COMM (MPPP/MPMP) board is shown in the following table:

Control COMM board 1 HL1 Green Runnin On simultaneously
layer (MPPP/MPMP) indicator g with the fault
board status indicator: The board
is faulty (the clock is
lost for instance).
16

On simultaneously
with the running
Red Board
2 HL2 indicator: The board
indicator failure
is faulty (the clock is
lost for instance).
1.10.4Checking Running Status of the COMM (MTP2) Board
[Maintenance tool]
(MTP2) board to judge its running status.
[Test procedure]
alarm from the COMM (MTP2) board.
2. Observe the panel indicators of the COMM (MTP2) board and judge its running status according
to whether the panel indicators are normal or abnormal.
[Normal result]
17
1. No current alarm is detected for the COMM (MTP2) board via the alarm management part of the
OMCR (V2) client.
2. The normal status of indicators on a COMM (MTP2) board is shown in the following table:

HL Green Running Flashing quickly: SS7 link
Control COMM 1
1 indicator status normal
layer board
HL Red Board Constantly off: Running
board (MTP2) 2
[Troubleshooting]
The abnormal status of indicators on a COMM (MTP2) board is shown in the following table:

HL Green Runnin Flashing slowly: The SS7
1
Control COMM 1 indicator g status link is broken.
layer board Flashing slowly: The board

HL Red Board
board (MTP2) 2 is faulty (the clock is lost
2 indicator failure
for instance).
18
1.10.5Checking Running Status of the ECOM (MTP2) Board
[Maintenance tool]
Observe alarms at the operation & maintenance background and the panel indicators of an ECOM
(MTP2) board to judge its running status.
[Test procedure]
from the ECOM (MTP2) board.
2. Observe the panel indicators of the ECOM (MTP2) board and judge its running status according
[Normal result]
1. No current alarm is detected for the ECOM (MTP2) board via the alarm management part of the
OMCR (V2) client.
2. The normal status of indicators on an ECOM (MTP2) board is shown in the following table:
19

HL Green Running Flashing quickly: Running
Control ECOM 1
1 indicator status normally
layer board
board (MTP2) 2
20
[Troubleshooting]
The abnormal status of indicators on an ECOM (MTP2) board is shown in the following table:

Control ECOM 1 HL Green Runni Flashing slowly: When the
layer board 1 indicator ng green indicator is off, it
board (MTP2) status indicates that the SS7 link is
broken; when it flashes slowly
together with the fault indicator,
it indicates that the
communication between the
ECOM board and MP is
interrupted.
Constantly off: Abnormal
21

Flashing slowly: When it
flashes slowly together with the
running indicator, it indicates
that the communication between
the ECOM board and MP is
Board
HL Red interrupted. Other status
2 failur
2 indicator indicates abnormality.
e
Constantly on: When it is
constantly on with the running
indicator, it indicates that the
clock is lost. Other status
indicates abnormality.
1.10.6Checking Running Status of the COMM (LAPD) Board
[Maintenance tool]
22
(LAPD) board to judge its running status.
[Test procedure]
alarm from the COMM (LAPD) board.
2. Observe the panel indicators of the COMM (LAPD) board and judge its running status according
[Normal result]
1. No current alarm is detected for the COMM (LAPD) board via the alarm management part of the
OMCR (V2) client.
2. The normal status of indicators on a COMM (LAPD) board is shown in the following table:

HL Green Running Flashing slowly: Running
Control COMM 1
1 indicator status normally
layer board
board (LAPD) 2
23
[Troubleshooting]
The abnormal status of indicators on a COMM (LAPD) board is shown in the following table:

Flashing slowly with the
fault indicator: The
Green Running board is faulty (the clock
1 HL1
indicator status is lost for instance).
Constantly on or
Control COMM constantly off: Abnormal
layer board Flashing slowly: The

board (LAPD) communication between
this board and MP fails.
Red Board
2 HL2 Flashing slowly with the
indicator failure
running indicator: The
board is faulty (the clock
is lost for instance).
24
1.10.7Checking Running Status of the ECOM (LAPD/MPPP/MPMP) Board
[Maintenance tool]
Observe alarms at the operation & maintenance background and the panel indicators of an ECOM
(LAPD/MPPP/MPMP) board to judge its running status.
[Test procedure]
from the ECOM (LAPD/MPPP/MPMP) board.
2. Observe the panel indicators of the ECOM (LAPD/MPPP/MPMP) board and judge its running
status according to whether the panel indicators are normal or abnormal.
[Normal result]
1. No current alarm is detected for the ECOM (LAPD/MPPP/MPMP) board via the alarm management
part of the OMCR (V2) client.
2. The normal status of indicators on an ECOM (LAPD/MPPP/MPMP) board is shown in the following
table:
25

Flashing slowly:
HL Green Running
Control 1 Running
ECOM board 1 indicator status
layer normally
(LAPD/MPPP/MPMP)
board HL Red Board Constantly off:
2
2 indicator failure Normal
[Troubleshooting]
The abnormal status of indicators on an ECOM (LAPD/MPPP/MPMP LAPD) board is shown in the
following table:
26
27

Flashing slowly
with the fault
indicator:
Indicates that the
communication
between the
ECOM board
and MP is
Control ECOM board HL Green Runnin
layer (LAPD/MPPP/MPMP 1 interrupted.
1 indicator g status
board ) Constantly on:
Abnormal
When it is
constantly on
with the fault
indicator, it
indicates that
the clock is lost.
Constantly off:
Abnormal
28
Flashing slowly
with the running
indicator:
Indicates that
the
communication
between the
ECOM board
HL Red Board and MP is
2
2 indicator failure interrupted.
When it is
constantly on
with the running
indicator, it
indicates that the
clock is lost.
29
1.10.8Checking Running Status of the PEPD (MON) Board
[Maintenance tool]
Observe alarms at the operation & maintenance background and the panel indicators of a PEPD (MON)
board to judge its running status.
[Test procedure]
alarm from the PEPD (MON) board.
2. Observe the panel indicators of the PEPD (MON) board and judge its running status according to
whether the panel indicators are normal or abnormal.
[Normal result]
1. No current alarm is detected for the PEPD (MON) board via the alarm management part of the
OMCR (V2) client.
2. The normal status of indicators on a PEPD (MON) board is shown in the following table:
30

Flashing slowly: Running
Green Runnin normally
Control PEPD 1 HL1
indicator g status Flashing quickly: Sensor
layer board
being preheated
board (MON)
Red Board Constantly off: Running
2 HL2
indicator failure normally
[Troubleshooting]
The abnormal status of indicators on a PEPD (MON) board is shown in the following table:

Green Runnin Constantly on or constantly
Control PEPD 1 HL1
indicator g status off: Abnormal
layer board
Red Board On: Board failure, such as
board (MON) 2 HL2
indicator failure dual-port RAM check error
31
1.10.9Checking Running Status of the PCOM Board
[Maintenance tool]
Observe alarms at the operation & maintenance background and the panel indicators of a PCOM board
[Test procedure]
alarm from the PCOM board.
2. Observe the panel indicators of the PCOM board and judge its running status according to whether
[Normal result]
1. No current alarm is detected for the PCOM board via the alarm management part of the OMCR
(V2) client.
2. The normal status of indicators on a PCOM board is shown in the following table:
Control PCOM board 1 HL Green Running Flashing slowly:
layer 1 indicator status Running normally
32
board HL Red Board Constantly off: Running
2
3 HL Green Sending Constantly on: The
3 indicator data to PCOM board sends data
dialing to the dialing MODEM.
MODEM Constantly off: The
PCOM board does not
send data to the dialing
MODEM.
33

Constantly on: The
PCOM board receives
Receivin
data from the dialing
g data
HL Green MODEM.
4 from
4 indicator Constantly off: The
dialing
PCOM board does not
MODEM
receive data from the
dialing MODEM.
5 HL Green Send Constantly on: The
5 indicator data to PCOM board is sending
data to the baseband
baseband MODEM.
MODEM Constantly off: The
PCOM board does not
send data to the
baseband MODEM.
34
Constantly on: The
PCOM board receives
Receivin
data from the baseband
g data MODEM.
HL Green
6 from Constantly off: The
6 indicator
baseband PCOM board does not
MODEM receive data from the
baseband MODEM.
[Troubleshooting]
The abnormal status of indicators on a PCOM board is shown in the following table:
Control PCOM 1 HL1 Green Runnin Flashing slowly with the
layer board indicator g status fault indicator:
board Communication with MP
interrupted
Constantly on or constantly
off: Abnormal
35

Flashing slowly with the
running indicator:
Communication with MP
Red Board interrupted
2 HL2
indicator failure Constantly on: Hardware
clock loss or other
hardware failure
36
1.10.10Checking Running Status of the BOSN Board
[Maintenance tool]
Observe alarms at the operation & maintenance background and the panel indicators of a BOSN board
[Test procedure]
from the BOSN board.
2. Observe the panel indicators of the BOSN board and judge its running status according to whether
[Normal result]
1. No current alarm is detected for the BOSN board via the alarm management part of the OMCR
(V2) client.
3. The normal status of indicators on a BOSN board is shown in the following table:
37

Flashing slowly:
Runni
Green Running normally
1 HL1 ng
indicator Flashing quickly: Data
status
loading synchronization
Network
switching Red Board Constantly off: Running
BOSN board 2 HL2
layer indicator failure normally
board Green Constantly on: Board
3 HL3 Active
indicator being active
Green Standb Constantly on: Board
4 HL4
indicator y being standby
[Troubleshooting]
The abnormal status of indicators on a BOSN board is shown in the following table:
38

Runni
Green Constantly on or constantly off:
1 HL1 ng
indicator Abnormal
status
Flashing slowly: The
Network
communication between this
switching BOSN
board and the upper-level board
layer board
Red Board fails. This board will be reset if
board 2 HL2
indicator failure the fault is not recovered within
a certain period of time.
On: The board is faulty (the
clock is lost for instance).
39
1.10.11Checking Running Status of the DSNI/COMI Board
[Maintenance tool]
Observe alarms at the operation & maintenance background and the panel indicators of a DSNI/COMI
[Test procedure]
alarm from the DSNI/COMI board.
2. Observe the panel indicators of the DSNI/COMI board and judge its running status according to
[Normal result]
1. No current alarm is detected for the DSNI/COMI board via the alarm management part of the
OMCR (V2) client.
2. The normal status of indicators on a DSNI/COMI board is shown in the following table:

Network DSNI/COMI 1 HL1 Green Runni Flashing slowly:
switching board indicator ng Running normally
layer status
40

Red Board Constantly off: Running
2 HL2
indicator failure normally
Green Constantly on: Board
board 3 HL3 Active
indicator being active
Green Standb Constantly on: Board
4 HL4
indicator y being standby
[Troubleshooting]
The abnormal status of indicators on a DSNI/COMI board is shown in the following table:

Network DSNI/ 1 HL Green Runni Flashing quickly: The
switching COMI 1 indicator ng communication between this
layer board status board and MP fails.
board Constantly on or constantly off:
Abnormal
41

Flashing slowly:
Communication failed between
this board and its upper level.
Board
HL Red The board will be reset if the
2 failur
2 indicator alarm is not recovered within a
e
certain period of time.
On: Board failure, such as clock
loss
1.10.12Checking Running Status of the CKI Board
[Maintenance tool]
Observe alarms at the operation & maintenance background and the panel indicators of a CKI board to
judge its running status.
[Test procedure]
alarm from the CKI board.
42
2. Observe the panel indicators of the CKI board and judge its running status according to whether
[Normal result]
1. No current alarm is detected for the CKI board via the alarm management part of the OMCR
(V2) client.
2. The normal status of indicators on a CKI board is shown in the following table:
Network CKI Green Running Constantly on: Running
switching board 1 HL1
indicator status normally
layer
board Red Constantly off: Running
2 HL2 Board failure
indicator normally
Green 8KHz clock On: 8K clock reference
3 HL3
indicator reference existent
Green 2MHz clock On: 2M clock reference
4 HL4
5 HL5 Green 5MHz clock On: 5M clock reference
43

Green 2Mb clock On: 2Mb clock reference
6 HL6
The four indicators show
the selected ones in the
16 references in the
binary system, which are
Reference arranged in the order of
Green higher bits to lower bits
7 HL7 selection
indicator from the top down (On:
indication 1; Off: 0):
0~3: E8K 0~3
4~7: 2MHz 0~3
8~11: 5MHz 0~3
12~15: 2MBT 0~3
On: Manually selects
clock reference enabling
Green Manual Off: Manually selects
11 HL11
indicator indication clock reference
disabling
44
45
[Troubleshooting]
The abnormal status of indicators on a CKI board is shown in the following table:
Network CKI board Runni Flashing quickly: The
switching HL Green
1 ng communication with the
layer 1 indicator
board status SYCK board is abnormal.
HL Red Board On: Board faulty
2
2 indicator failure
8KHz Off: 8K clock reference
HL Green clock nonexistent
3
3 indicator refere
nce
4 HL Green 2MHz Off: 2M clock reference
4 indicator clock nonexistent
refere
nce
46
5MHz Off: 5M clock reference
5
5 indicator refere
nce
2Mb Off: 2Mb clock reference
6
6 indicator refere
nce
1.10.13Checking Running Status of the SYCK Board
[Maintenance tool]
Observe alarms at the operation & maintenance background and the panel indicators of an SYCK board
[Test procedure]
from the SYCK board.
47
2. Observe the panel indicators of the SYCK board and judge its running status according to whether the
panel indicators are normal or abnormal.
[Normal result]
1. No current alarm is detected for the SYCK board via the alarm management part of the OMCR
(V2) client.
2. The normal status of indicators on an SYCK board is shown in the following table:
Boa Locatio Nam Descripti Meani
Category Work Mode
rd n e on ng
Network SYCK Runni
switching board Green
1 HL1 ng Constantly on: Running normally
layer indicator
board status
Red Board
2 HL2 Off: Running normally
indicator failure
Green Activ On: Board being active
3 HL3
indicator e Off: Board being standby
4 HL4 Green Stand On: Board being standby
indicator by Off: Board being active
48
Boa Locatio Nam Descripti Meani

Category Work Mode
rd n e on ng
Fast
On: Board in the fast pull-in status
Green pull-
5 HL5 Off: Board not in the fast pull-in
indicator in
status
status
Continued
Network SYCK On: Board in the locked status
switching board Green Locked
6 HL6 Off: Board not in the locked
layer indicator status
board status
7 HL7 Green Holdov On: Board in the holdover status
indicator er status Off: Board not in the holdover
status
49

8 HL8 Green Free On: Board in the free run status
indicator run On: Board not in the free run
status status
50
Three indicators HL9~HL11
constitute a three-bit binary
code. Here, HL9 is the higher
bit while HL11 is the lowest bit.
“1” indicates that the indicator
is on while “0” indicates that it
is off. The specific meanings are
Referen
as follows:
Green ce
9 HL9 HL9~HL11 being 000: No
indicator selectio
clock reference
n
HL9~HL11 being 001~100:
Selects local board clock
references. Four local board
clock references are available.
HL9~HL11 being 101: Selects
the clock reference sent from
CKI.
51

On: Manually selects clock
Manual
HL1 Green reference enabling.
12 enablin Off: Manually selects clock
2 indicator
g reference disabling.
[Troubleshooting]
The abnormal status of indicators on a SYCK board is shown in the following table:

Runni
Network HL Green
1 ng Constantly off: Abnormal
switching 1 indicator
SYCK board status
layer
HL Red Board
board 2 On: The board is faulty.
2 indicator failure
[Recovery after test] None.
1.10.14Checking Running Status of the DRT/EDRT Board
[Maintenance tool]
52
Observe alarms at the operation & maintenance background and the panel indicators of a DRT/EDRT
[Test procedure]
alarm from the DRT/EDRT board.
2. Observe the panel indicators of the DRT/EDRT board and judge its running status according to
[Normal result]
1. No current alarm is detected for the DRT/EDRT board via the alarm management part of the
OMCR (V2) client.
2. The normal status of indicators on a DRT/EDRT board is shown in the following table:
53

normally
Runni Flashing quickly:
Green
1 HL1 ng Communication failed
indicator
status between this board and MP
off: Abnormal
TC unit DRT/EDRT
Red Board
board board 2 HL2 Off: Running normally
indicator failure
On: No speech channel is
being processed for all
Green Idle DSPs.
3 HL3
indicator status Off: One or some speech
channels are being
processed.
54
[Troubleshooting]
The abnormal status of indicators on a DRT/EDRT board is shown in the following table:

TC unit DRT/EDRT 1 HL1 Green Runni Flashing quickly:
board board indicator ng Communication failed
status between this board and MP
off: Abnormal
55
Flashing slowly:
Communication failed
between this board and its
upper level. The board will
Red Board be reset if the alarm is not
2 HL2
indicator failure recovered within a certain
period of time.
On: The board is faulty
(the clock is lost for
instance).
1.10.15Checking Running Status of the TIC/DTI Board
[Maintenance tool]
Observe alarms at the operation & maintenance background and the panel indicators of a TIC/DTI board
[Test procedure]
56
from the TIC/DTI board.
2. Observe the panel indicators of the TIC/DTI board and judge the work status of this board according
to whether the indicators on the panel are normal or abnormal.
[Normal result]
1. No current alarm is detected for the TIC/DTI board via the alarm management part of the OMCR
(V2) client.
2. The normal status of indicators on a TIC/DTI board is shown in the following table:

TC unit TIC/DTI Runni
HL Green Flashing slowly: Running
board board 1 ng
1 indicator normally
status
HL Red Board
2 Off: Running normally
2 indicator failure
HL Green Flashing quickly: Running
3 DT1
4 HL Green DT2 Flashing quickly: Running

57

5 DT3
6 DT4
[Troubleshooting]
The abnormal status of indicators on a TIC/DTI board is shown in the following table:
TC unit TIC/DTI 1 HL Green Running Flashing quickly:
board board 1 indicator status Communication failed between
this board and MP
Constantly on or constantly off:
Abnormal
58
Flashing slowly:
Communication failed between
this board and its upper level.
HL Red Board The board will be reset if the
2
2 indicator failure alarm is not recovered within a
certain period of time.
On: The board is faulty (the
clock is lost for instance).
HL Green Constantly on: Alarm
3 DT1
3 indicator Off: E1 interface not initialized
TC unit TIC/DTI Constantly on: Alarm
HL Green
board board 4 DT2 Off: E1 interface not
4 indicator
initialized
5 HL Green DT3 Constantly on: Alarm
5 indicator Off: E1 interface not
initialized
59

HL Green DT4 Constantly on: Alarm
6 Off: E1 interface not
6 indicator
initialized
1.10.16Checking Running Status of the GPP Board
[Maintenance tool]
Observe alarms at the operation & maintenance background and the panel indicators of a GPP board to
[Test procedure]
alarm from the GPP board.
2. Observe the panel indicators of the GPP board and judge its running status according to whether
[Normal result]
1. No current alarm is detected for the GPP board via the alarm management part of the OMCR
60
(V2) client.
2. The normal status of indicators on a GPP board is shown in the following table:

normally
Flashing quickly: If it is not
HL Green Running
1 flashing slowly with the red
1 indicator status
indicator, it indicates that data
is being acquired from the
TC unit database.
GPP board
board
HL Red Board
2 indicator failure
HL Green On: Board being active
3 Active
3 indicator Off: Board being standby
HL Green On: Board being standby
4 Standby
4 indicator Off: Board being active
61
[Troubleshooting]
The abnormal status of indicators on a GPP board is shown in the following table:

Flashing quickly: If it
flashes slowly with the red
indicator, it indicates that
HL Green Running
1 the HDLC communication
1 indicator status
is interrupted.
TC unit Constantly on or constantly

GPP board
board off: Abnormal
Flashing slowly: HDLC
communication interrupted
HL Red Board
2 On: The board is faulty
2 indicator failure
instance).
62
1.10.17Checking Running Status of the PUC Board
[Maintenance tool]
Observe alarms at the operation & maintenance background and the panel indicators of a PUC board to
[Test procedure]
alarm from the PUC board.
3. Observe the panel indicators of the PUC board and judge its running status according to whether
[Normal result]
1. No current alarm is detected for the PUC board via the alarm management part of the OMCR
(V2) client.
2. The normal status of indicators on a PUC board is shown in the following table:
63

HL1 flashing slowly while HL2
off: Running normally
HL1 flashing quickly while HL2
HL Green Runnin
1 off: Waiting for data
1 indicator g status synchronization
HL1 and HL2 flashing slowly
simultaneously: Program loading
GPRS PUC
PP board board HL Red Board
2 indicator failure
3 Active
4 Standby
64
[Troubleshooting]
The abnormal status of indicators on a PUC board is shown in the following table:

Flashing quickly: HDLC
between this board and the
GPRS Red Board
PUC board 2 HL2 upper-level board is
PP board indicator failure
broken.
Constantly on: Clock lost
1.10.18Checking Running Status of the BRP Board
[Maintenance tool]
Observe alarms at the operation & maintenance background and the panel indicators of a BRP board to
[Test procedure]
alarm from the BRP board.
2. Observe the panel indicators of the BRP board and judge its running status according to whether
65
[Normal result]
1. No current alarm is detected for the BRP board via the alarm management part of the OMCR (V2)
client.
2. The normal status of indicators on a BRP board is shown in the following table:

GPRS BRP HL1 flashing slowly while
PP board board HL2 off: Running normally
HL1 flashing quickly while
HL Green Runnin HL2 off: Waiting for data
1
simultaneously: Program
loading
2 HL Red Board Off: Running normally
2 indicator failure
66
HL Green Flashing slowly: DSP1
3 DSP1
3 indicator program being executed
4 DSP2
[Troubleshooting]
The abnormal status of indicators on a BRP board is shown in the following table:

GPRS BRP board Flashing quickly: HDLC
PP board Board between this board and the
HL Red
2 failur upper-level board is
2 indicator
e broken.
3 HL Green DSP1 Other status: Abnormal

3 indicator
67

HL Green
4 DSP2 Other status: Abnormal
4 indicator
68
1.10.19Checking Running Status of the FRP Board
[Maintenance tool]
Observe alarms at the operation & maintenance background and the panel indicators of an FRP board to
[Test procedure]
alarm from the FRP board.
2. Observe the panel indicators of the FRP board and judge its running status according to whether
[Normal result]
1. No current alarm is detected for the FRP board via the alarm management part of the OMCR
(V2) client.
2. The normal status of indicators on an FRP board is shown in the following table:
69

HL1 flashing slowly while
HL2 off: Running normally
HL1 flashing quickly while
HL Green Running HL2 off: Waiting for data
1 synchronization
1 indicator status
simultaneously: Program
GPRS FRP loading
PP board board
HL Red Board
2 indicator failure
HL Green Flashing slowly: DSP1 program
3 DSP1
3 indicator being executed
4 DSP2
[Troubleshooting]
The abnormal status of indicators on an FRP board is shown in the following table:
70

between this board and the
HL Red Board
2 upper-level board is
2 indicator failure
broken.
GPRS Constantly on: Clock lost
FRP board
PP board
HL Green Other status instead of
3 DSP1
3 indicator flashing slowly: Abnormal
HL Green Other status instead of
4 DSP2
4 indicator flashing slowly: Abnormal
1.10.20Checking Running Status of the GIPP Board
[Maintenance tool]
Observe alarms at the operation & maintenance background and the panel indicators of a GIPP board to
71
[Test procedure]
alarm from the GIPP board.
2. Observe the panel indicators of the GIPP board and judge its running status according to whether
[Normal result]
1. No current alarm is detected for the GIPP board via the alarm management part of the OMCR
(V2) client.
2. The normal status of indicators on a GIPP board is shown in the following table:
GPRS GIPP HL1 flashing slowly while HL2
PP board board off: Running normally
HL1 flashing quickly while HL2
HL Green Runnin
1 off: Waiting for data
simultaneously: Program loading
2 HL Red Board Off: Running normally
2 indicator failure
72
3 Active
4 Standby
[Troubleshooting]
The abnormal status of indicators on a GIPP board is shown in the following table:

GPRS PP GIPP Red Board between this board and the

2 HL2
board board indicator failure upper-level board is broken.
1.10.21Checking Running Status of the POWB Board
[Maintenance tool]
Observe alarms at the operation & maintenance background and the panel indicators of a POWB board
73

[Test procedure]
from the POWB board.
2. Observe the panel indicators of the POWB board and judge its running status according to whether
[Normal result]
1. No current alarm is detected for the POWB board via the alarm management part of the OMCR
(V2) client.
2. The normal status of indicators on a POWB board is shown in the following table:

Runni
Green
Power 1 HL1 ng On: Running normally
POWB indicator
unit status
board
board Red Board
indicator failure
74
[Troubleshooting]
The abnormal status of indicators on a POWB board is shown in the following table:

Green Runnin
Power 1 HL1 Off: Board failure
POWB indicator g status
unit
board Red Board
board 2 HL2 On: Board failure
indicator failure
75
1.10.22Checking Running Status of the POWP Rack Power Distributor
[Maintenance tool]
Observe alarms at the operation & maintenance background and the panel indicators of a POWP board
[Test procedure]
from the POWP board.
2. Observe the panel indicators of the POWP board and judge its running status according to whether
[Normal result]
1. No current alarm is detected for the POWP board via the alarm management part of the OMCR
(V2) client.
2. The normal status of indicators on a POWP rack power distributor is shown in the following
table:

Power POWP rack 1 HL1 Green Fan power On: Running
unit power indicator indication normally
76

Green Power On: Running
2 HL2
indicator indicator normally
Power
Red Off: Input voltage
3 HL3 undervoltage
board distributor indicator normal
indication
Power
Red Off: Input voltage
4 HL4 overvoltage
indicator normal
indication
Note: The indicators and switches on POWP are arranged in the order of 1, 2, 3, …, 5 successively from
left to right.
[Troubleshooting]
The abnormal status of indicators on a POWP rack power distributor is shown in the following table:

Power POWP rack 3 HL Red Power On: Input
unit power 3 indicator undervoltage undervoltage
board distributor indication
77
Power
HL Red
4 overvoltage On: Input overvoltage
4 indicator
indication
1.10.23Checking Running Status of the SMB Board
[Maintenance tool]
Observe alarms at the operation & maintenance background and the panel indicators of a SMB board to
[Test procedure]
alarm from the SMB board.
2. Observe the panel indicators of the SMB board and judge its working status according to
indicators on the panel.
[Normal result]
1. No current alarm is detected for the SMB board via the alarm management part of the OMCR
(V2) client.
2. The normal status of indicators on an SMB board is shown in the following table:
78
Green Running Flashing slowly: Running
1 HL1
indicator status normally
Red Board
indicator failure
Flashing quickly: Running
Green normally
3 HL3 E1-1
indicator Off: E1 interface not
Other configured
SMB board
boards Flashing quickly: Running
Green normally
4 HL4 E1-2
configured
Flashing quickly: Running
Green normally
5 HL5 E1-3
configured
79
[Troubleshooting]
The abnormal status of indicators on an SMB board is shown in the following table:
Other SMB board HL Green Running Constantly on or constantly
boards 1
1 indicator status off: Abnormal
Flashing slowly: The
communication between
this board and the upper-
level board fails. This
board will be reset if the
HL Red Board fault is not recovered
2
2 indicator failure within a certain period of
time.
On: The board is faulty
instance).
3 HL Green E1-1 On: E1 alarm
3 indicator
80
HL Green
4 E1-2 On: E1 alarm
4 indicator
HL Green
5 E1-3 On: E1 alarm
5 indicator
.
1.10.24Checking Running Status of the TMM Module
[Maintenance tool]
Observe the panel indicators of the TMM module to judge its running status.
[Test procedure]
Observe the panel indicators of the TMM module and judge its running status according to whether the
panel indicators are normal or abnormal.
[Normal result]
The normal status of indicators on a TMM module is shown in the following table:
Other TMM 1 PW Green/red Power Green: Normal
boards module R indication
81

Green indicator
flashing slowly:
Running Running; Green
2 RUN Green indicator flashing
indication
together with the
STA indicator:
Software download
Flashing quickly: E1
connected
3 SYN Green/red E1 status
Off: Board in the
BOOT status
4 CLK Green/red Standby -
Active/stand Constantly on:
5 MST Green
by indication Active board
Board STA and RUN
flashing quickly:
6 STA Green/red failure
Software download;
indication Off: Normal
[Troubleshooting]
82
The abnormal status of the TMM module is shown in the following table:
PW
1 Green/red Power indication Off: Power off
R
RU Running Green indicator off:
2 Green
N indication Abnormal
SY Constantly on: E1
3 Green/red E1 status
N broken
CL
Other TMM 4 Green/red Standby -
boards module K
MS Active/standby
5 Green Off: Unknown
T indication
Flashing quickly with
RUN flashing slowly:
ST Board failure The board is started
6 Green/red
A indication but the link with the
background is
broken.
83
1.10.25 Supplementary Description of Indicators
During version loading of the BSC (V2) board, the status of two indicators: HL1 and HL2 is shown in
the following table:
Location Name Description Meaning Work Mode
Flashing slowly: Ready for
loading
Green Flashing quickly: Loading
1 HL1 Running status
indicator underway
Constantly on or constantly off:
Abnormal
Flashing quickly: Running in
BOOT. It is only aimed at some
Red
2 HL2 Board failure boards needing version loading,
indicator
such as BOSN, DRT, EDRT and
GPP.
84
1.11 Checking Running Status of the Background Server
1.11.1 Viewing Running Status of the Background Server Process with omcps
Tool
[Maintenance tool]
View the number of processes and process start time at the server console with the omcps tool to check
the running status of background server processes.
[Test procedure]
Run the “omcps” command in the server console to view whether each process has been started
normally.
A command example is as follows:
bash-2.02$ omcps
FsmLength=400 sizeof (TpssInfo)=20
Pno PPno Pname Daemon Status StartTime
1 0 GPO TRUE STARTED 2/13 18:29:50
0 0 FALSE STARTED 2/13 18:29:50
2 0 MPCOMM TRUE STARTED 2/13 18:29:50
85
11 0 MPAA TRUE STARTED 2/13 18:29:50

12 0 CCF TRUE STARTED 2/13 18:29:51
13 0 ACF TRUE STARTED 2/13 18:29:51
4 0 LMF TRUE STARTED 2/13 18:29:52
14 0 AGT TRUE STARTED 2/13 18:29:53
15 0 IMF TRUE STARTED 2/13 18:29:54
16 0 BAF TRUE STARTED 2/13 18:29:54
17 0 SMF TRUE STARTED 2/13 18:29:54
18 0 MPAC TRUE STARTED 2/13 18:29:54
19 0 PMONLAF TRUE STARTED 2/13 18:29:55
20 0 CRON TRUE STARTED 2/13 18:29:55
21 0 RLOG TRUE STARTED 2/13 18:29:55
22 0 FTP TRUE STARTED 2/13 18:29:56
24 0 FALSE STARTED 2/13 18:32:17
 Tips: In this command instance, the meaning of each field is as follows: “Pno” indicates the
process number; “Ppno” indicates the parent process number; “Pname” indicates the process
name; “Daemon” indicates the running status; “Status” refers to the start status; and
86
“StartTime” is the start time. “Daemon” being TRUE means the normal status; FALSE means
the abnormal status. If the StartTime of a process is changing, it indicates that this process is
restarted repeatedly.
[Normal result]
1. The GPO, MPCOMM, DIF, MPAA, CCF, ACF, LMF, AGT, IMF, BAF, SMF, MPAC, PMONLAF,
CRON, RLOG and FTP processes all exist and their Daemon values are all TRUE.
 Tips: If multiple MPCOMM processes are true, in normal status, the Daemon value of the
MPCOMM process with the “Pno" of 2 is TRUE while the values of all other MPCOMM processes are
FALSE.
2. The start time of each process should be the same approximately.
[Troubleshooting]
1. Run “omcps” as an omc user. If there is no input, the system may by faulty. In this case, please restart
the OMCR (V2) system immediately. If the restart fails, please restart the server system.
Please refer to the following procedures for restart of the server system:
1) Shut down the OMCR (V2) system.
2) Shut down Oracle.
87
3) Restart the server.

4) Restart the database. If the database cannot be automatically started, please start it manually.
5) Restart the OMCR (V2) system.
2. In the GPO, MPCOMM, DIF, MPAA, CCF, ACF, LMF, AGT, IMF, BAF, SMF, MPAC, PMONLAF,
CRON, RLOG and FTP processes, if the Daemon value of a process is FALSE, it indicates that this
process may be running abnormally. If necessary, please restart this process.
3. If there is any process after RLOG with a process name, please check whether the start time of this
process is close to that of RLOG. It is normal if the difference is within 1 minute. Otherwise, it indicates
that some fault has occurred to this process. If there are two or more than two processes after RLOG
with process names, it is recommended to restart all server processes. If there is only one, please
continue with the observation.
4. If the difference between the start time of a process and that of other processes (exceeding 30 seconds
for instance), it is necessary to view the process log file and confirm whether to manually start OMCR
(V2) or let it restart automatically and find the restart cause. Generally, process without process names
have no influence on the daily operation. However, some timing tasks may be abnormal. In this case, it
88
is recommended to restart all sever processes.
[Precautions]
During normal start of OMCR (V2), there are multiple running processes, which can be divided into
three parts: application, communication and database. As the site scale varies, these processes may be
run with either a single server or multiple servers. For example, the application and communication
processes of OMCR (V2) run in the application server while the database processes run in the database
server. In this section, the single-server environment is taken for example to describe how to check
whether all the background server processes are running normally.
1.11.2Viewing Process Memory Occupation with TOP Tool
[Maintenance tool]
At the server console, use the TOP tool to check a process’s CPU occupation ratio, swap memory size
and so on.
[Test procedure]
Run the “TOP -U (User)” command in the server console. A command example is as follows:
bash-2.02$ top -U omc
89
last pid: 4598; load averages: 0.56, 0.49, 0.47 11:54:01
76 processes: 75 sleeping, 1 on cpu
CPU states: 96.2% idle, 2.0% user, 1.4% kernel, 0.4% iowait, 0.0% swap
Memory: 512M real, 7904K free, 464M swap in use, 563M swap free
90
T COM
USER NIC SIZ TIM
PID H PRI RES STATE CPU MAN
NAME E E E
R D
458 omc 18 58 0 337 34M sleep 203:5 4.00 agt
M 4 %
467 omc 11 59 0 13M 636 sleep 109:2 3.49 fmfilt
0K 1 % er
459 omc 1 18 0 1568 131 cpu 0:00 1.40 top

8 K 2K %
462 omc 15 58 0 17M 812 sleep 50:00 1.11 baf_n
8K % ew
477 omc 1 58 0 59M 44M sleep 208:2 1.07 oracle

2 %
456 omc 9 59 0 13M 494 sleep 10:52 0.60 ccf
4K %
459 omc 11 58 0 12M 588 sleep 26:51 0.46 lmf
91
8K %
454 omc 16 59 0 26M 815 sleep 21:49 0.44 diffs
2K %
452 omc 57 58 0 5536 312 sleep 27:31 0.38 gpo
K 0K %
453 omc 31 58 0 4224 227 sleep 9:54 0.35 mpco
K 2K % mm
457 omc 7 58 0 11M 462 sleep 5:21 0.17 acf
4K %
459 omc 1 48 0 2136 164 sleep 0:00 0.09 bash
2 K 0K %
469 omc 10 58 0 52M 29M sleep 7:01 0.03 topm
%
466 omc 8 59 0 17M 735 sleep 0:15 0.01 pmonl
2K % af
[Normal result]
92
In normal cases, the free swap space should be not less than 200M and the maximum CPU occupation
ratio of a process should be not more than 80%.
[Troubleshooting]
1. If the free swap space or the CPU occupation ratio of a process is abnormal, it is possible that the
server is running abnormally or the process is being restarted. Please wait for a while (about 10~30
minutes) and then observe whether the situation firms up.
2. If the abnormality remains, it is recommended to restart the process with a higher CPU occupation
ratio.
3. If the system is still abnormal after restart of a single process, you may restart all server processes.
93
[Precautions]
The process names displayed on the “top” are physical process names; while those displayed in “omcps”
are logic process names. The corresponding relationship between them is shown in the table below,
which may vary in actual applications and can be determined by viewing the “syscfg.ini” file in the
server.
Physical Process Logic Process Name Physical Process Logic Process Name
Name Name
gpo GPO fmfilter FMFILTER
mpcomm MPCOMM fmdisp FMDISP
ccf CCF fmplate FMPLATE
diffs DIF diaglmf DIAGLMF
acf ACF opmadmd OPMADMD
baf_new BAF pmonlaf PMONLAF
lmf LMF pmonlmf PMONLMF
agt AGT ftp FTP
cmproc MCM omccron CRON
smf SMF cmagt CMA
94
mpac MPAC cmgetdb CMGETDB
mpaa MPAA rlog RLOG
topm TOPM
1.12 Service Performance Check
1.12.1 System Performance Monitoring
[Maintenance tool]
At the server console, run commands like “uptime”, “sar –q” and “sar –u” to monitor the system
performance.
Here, the “uptime” command is a simple method used to monitor the system performance. This
command is used to display the process information in the system running queue within a certain
interval. By approximate analysis of such information, we can get the workload of the server. When the
system performance deteriorates, please first run the “uptime” command to observe the basic status of
the system performance.
[Test procedure]
1. Run the “uptime” command to monitor the system performance.
95

$ uptime
11:22am up 1 day (s), 18:34, 11 users, load average: 0.04, 0.02, 0.03
 Tips: The useful information here is the average values of three loads (load averages),
in which 0.04, 0.02 and 0.03 are the load averages within the first 1 minute, 5 minutes and 15
minutes respectively.
2. Run the “sar –q” command to monitor the system performance.

$sar –q 5 5
15:38:36 runq-sz %runocc swpq-sz %swpocc
15:38:41 5.0 100
15:38:46 5.0 100
15:38:51 4.8 100
15:38:56 4.8 100
15:39:01 4.6 100
Average 4.8 100
96
The meaning of each field is as follows:
runa-sz: Is the running queue length within a certain interval.
%runocc: Is the time percentage occupied by processes in the running queue.
swpq-sz: Is the swap queue length within a certain interval.
%swpocc: Is the time percentage occupied by processes in the swap queue.
3. Run the “sar –u” command to monitor the system.

$ sar –u 5 5
15:47:26 %usr %sys %wio %idle
15:47:31 0 1 1 98
15:47:36 0 1 1 97
15:47:41 0 0 0 99
15:47:46 0 2 0 98
15:47:51 0 0 0 99
Average 0 1 1 98
%usr: Is the time percentage occupied when the CPU is executed in the user status.
97
%sys: Is the time percentage occupied when the CPU is executed in the kernel status.
%wio: Is the time percentage occupied when the CPU waits for I/O.
%idle: Is the time percentage occupied when the CPU is idle.
[Normal result]
For a large-scale Unix system, load averages 2 and 3 indicate light load; 5 and 6 indicate medium load;
and the values above 10 indicate overload.
[Troubleshooting]
If the “%idle” value is high while the system load is heavy, there may be some problem with the
memory or I/O system. If the “%wio” value is very high, please check the efficiency of the I/O
subsystem.
1.12.2 Monitoring Memory Occupation
[Maintenance tool]
At the server console, run commands like “vmstat” and “sar –wpgr” to monitor the memory
performance.
The “vmstat” command is used to check the virtual memory statistics information. It can also be used to
display information like the process status, idle and swap space, paging, disk space, CPU load and swap,
Cache refresh and break.
98
The “sar –wpgr” command can be used to display information about use of memory resources by most
systems.
[Test procedure]
1. Run “vmstat” to monitor the memory performance.
Command format: vmstat t[n]
This command is to perform sampling for n times within a t-second interval.
vmstat –s 5
proc memory page disk faults cpu
r b w swap free re mf pi po fr de sr f0 s0 s1 s2 in sy cs us sy id
0 0 0 336096 218880 0 6 22 0 0 0 0 0 2 2 1 366 1856 80 0 1 99
0 0 0 330384 160432 0 0 0 0 0 0 0 0 0 1 0 340 1963 64 0 1 99
0 0 0 330384 160432 0 0 0 0 0 0 0 0 2 2 0 368 2796 63 1 2 99
0 0 0 330384 160432 0 0 0 0 0 0 0 0 0 1 0 348 1926 60 0 0 99
0 0 0 330384 160432 0 0 0 0 0 0 0 0 0 1 0 351 1845 58 0 1 99
0 0 0 330384 160432 0 0 0 0 0 0 0 0 0 1 0 334 1130 59 0 1 99
99
Procs: Indicates the number of processes in each status.

r: Is in the running queue.
b: Waits for resources after being blocked.
w: Waits for processing resources after being swapped.
memory: Report the actual and virtual memory quantity.
swap: Is the free swap space.
free: Is the size of the free list.
page: Reports the page fault and dispatch times within a certain interval and one second.
re: Refers to pages contained in the free list.
mf: Indicates the minor fault.
si: Is the number of paged-in pages.
pi: Is the number of paged-in bytes (unit: Kbytes).
po: Is the number of paged-out bytes (unit: Kbytes).
fr: Is the number of idle bytes (unit: Kbytes).
de: Is the anticipated short-term memory shortfall.
sr: Refers to the pages scanned by the clock algorithm per second.
disk: Refers to the disk operation times per second.
fault: Refers to the trap/interruption times.
100
in: Refers to device interruption.
sy: Refers to system faults per second.
cs: Refers to CPU context switching.
CPU: Refers to CPU use time.
us: Refers to the user time.
sy: Refers to the system time.
id: Refers to the idle time.
2. Run “sar –wpgr” to monitor the memory performance.

$ sar –wpgr 5 5
17:14:07 swpin/s bswin/s swpot/s bswot/s pswch/s
atch/s pgin/s ppgin/s pflt/s vflt/s slock/s
pgout/s ppgout/s pgfree/s pgscan/s %ufs_ipf
freemem freeswap
17:14:12 0.00 0.0 0.00 0.0 69
0.00 0.00 0.00 1.20 1.00 0.00
0.00 0.00 0.00 0.00 0.00
101
20058 661531
17:14:17 0.00 0.0 0.00 0.0 61
0.00 0.00 0.00 0.00 0.20 0.00
0.00 0.00 0.00 0.00 0.00
19978 658890
swpin/s: Refers to the times of writing to the memory per second.

bswin/s: Refers to the times of swapping to the memory data block.
swpot/s: Refers to the times of transmission from the memory to the swapping area per second.
bswot/s: Refers to the times of swapping out from the memory data block per second.
pswch/s: Refers to the times of process switching per second.
atch/s: Refers to the page fault times per second.
pgin/s: Refers to the times of requesting page-in to the memory by the file system per second.
ppgin/s: Refers to pages paged-in to the memory.
pflt/s: Refers to page faults caused by protection errors per second.
vflt/s: Refers to the address translation page faults per second.
slock/s: Refers to faults per second caused by software lock requested by I/O.
102
pgout/s: Refers to the page-out requests per second of the file system.
ppgout/s: Refers to the pages paged-out per second.
pgfree/s: Refers to the pages per second placed on the free list by the page stealing daemon.
(When this value is quite high, it indicates that the system needs more memory.)
pgscan/s: Refers to the pages per second scanned by the page stealing daemon. (When this value
is quite high, it indicates that the system needs more memory.)
%ufs_ipf: Is the percentage of ufs inodes taken off the free list which had reusable pages
associated with them. (When this value is quite high, it indicates it is necessary to add ufs
inodes.)
freemem: Refers to the average pages available to user processes in the system.
freeswap: Refers to the disk blocks available for page swapping.
For the detailed meaning of each field, please refer to the online Solaris manual.
[Normal result]
The value of each field is normal. For details, please refer to the online Solaris manual.
[Troubleshooting]
1. When “vmstat” is used to monitor the memory performance:
The “po”, “w” and “so” domains are closely related to the memory performance. These fields
103
reflect the paging and swapping time. When “w” is a non-zero value, “so” shows that swapping
occurs incessantly and the “po” value is at the high level all the time, it indicates that the memory
problem in the system is very serious.
2. When “sar –wpgr” is used to monitor the memory performance:
When the “swpot/s” value is more than 1, it indicates that more memory should be installed.
When the “pgfree/s” value is quite high, it indicates that the system needs more memory.
When the “pgscan/s” value is quite high, it indicates that the system needs more memory.
When the “%ufs_ipf” value is quite high, it indicates that it is necessary to add ufs inodes.
104
1.12.3 Monitoring Performance of the Disk System
[Maintenance tool]
Run the “iostat” and “df” command to check the disk system performance.
The “iostat” command is used to check the disk input/output and generate reports on the throughput,
utilization ratio, queue length, transmission rate and service time.
The “df” command is used to check whether any partition disk space of the sever overflows. The most
biggest and most common problem encountered during system running is that the disk space overflows,
especially the /tmp and /usr space. The “df” command can be used to report the free space in every
installed disk.
[Test procedure]
1. Run the “iostat” command to check the disk performance.
$ iostat 5
tty fd0 sd0 sd1 sd2 cpu
tin tout kps tps serv kps tps serv kps tps serv kps tps serv us sy wt id
0 7 0 0 0 9 1 45 12 1 20 3 0 17 0 1 1 98
0 47 0 0 0 38 5 42 21 3 26 4 1 12 0 1 3 95
105
0 16 0 0 0 8 1 14 5 1 15 0 0 0 0 1 0 99
0 16 0 0 0 0 0 16 10 1 19 0 0 0 0 1 1 98
0 16 0 0 0 8 0 17 10 1 20 0 0 0 0 1 0 99
0 16 0 0 0 1 0 12 5 1 21 0 0 0 0 0 0 99
The first line of the report displays the statistics information since the last system boot. Each
subsequent line displays the statistics information acquired every 5 seconds.
For the terminal:
tin: Refers to the characters in the terminal input queue.

tout: Refers to the characters in the terminal output queue.
For the disk:
bps: Refers to the number of blocks transmitted per second.

tps: Refers to the transmission times per second.
serv: Is the average service time (unit: ms).
For the CPU:
106
us: Is the time in the user status.
sy: Is the time in the kernel status.
wt: Is the I/O waiting time.
id: Is the idle time.
2. Run the “df” command to check whether any partition disk space of the server overflows.
bash-2.02$ df -k
Filesystem kbytes used avail capacity Mounted on

/dev/dsk/c0t0d0s0 962571 19298 885519 3% /
/dev/dsk/c0t0d0s5 3009327 589768 2359373 20% /usr
/proc 0 0 0 0% /proc
fd 0 0 0 0% /dev/fd
/dev/dsk/c0t0d0s3 962571 133202 771615 15% /var
/dev/dsk/c0t0d0s6 5289294 2976788 2259614 57% /export/home
/dev/dsk/c0t0d0s4 3009327 1624031 1325110 56% /opt
/dev/dsk/c0t0d0s7 3004615 326127 2618396 12% /oracleapp
/dev/dsk/c0t1d0s0 5043518 3266487 1726596 66% /oracleapp/u1
107

swap 898504 40 898464 1% /tmp
The meaning of each field is as follows (unit: K b):
kbyte: Refers to all free space of the file system.

used: Refers to the used space.
avail: Refers to the free (available) space.
capacity: Refers to the percentage taken by the used space.
mount on: Refers to the mount point.
Here, the available space is the actual free space minus a 10% reserved head space.
[Normal result]
The space of each partition is sufficient.
[Troubleshooting]
If the capacity (utilization ratio) is 100%, it indicates that the corresponding partition space overflows.
The “mount on” shows partitions. If the “/”, “/tmp”, “/var” or “/export/home” partition overflows, the
problem is very serious, which may lead to abnormal running of the system. Of course, overflow of any
108
other partition may also have some indirect influence on the system.
For an overflowing partition, please delete some files according to actual needs. For the “/export/home”
partition, you can delete files under the “tmp/log” (reserving those of the latest 7 days) and “tmp/ftp”
directories.
1.13 Checking Whether Database Running Is Normal
[Maintenance tool]
To ensure normal running of the OMCR (V2) system, please make sure that the database is running
normally. Generally, the tools provided by the server are used to check whether the database is running
normally.
[Test procedure]
1. Oracle database
1) Check whether the Oracle database has been started.
Generally, the Oracle database startup includes two steps, which are startup of the Oracle service
and startup of the Oracle Listener service.
109
If the oracle service has been started, the relevant prompt will be given on the screen.
If the Oracle Listener service has been started, the relevant prompt will be given on the screen
too.
2) Check whether you can connect to the Oracle database.
Log in to the Oracle database to check whether the sqlplus connection is normal.
If an SQL> prompter appears, it indicates that you have successfully logged in to the Oracle and
you can perform database operations.
2. Db2 database
1) Check whether the Db2 database instance has been started.
If the Db2 instance has been started, the relevant prompt will be given on the screen.
2) Check whether you can connect to the Db2 database.
Log in to the Db2 database to check whether the its connection is normal.
If a db2 => prompter appears, it indicates that you have successfully logged in to Db2 and you
can perform database operations.
110
[Normal result]
The database has been started and successful login is available.
[Troubleshooting]
If the database has not been started, please restart it. If you cannot log in to the database after start of it,
please check whether the user name and password are correct.
111
1.14 Checking Whether the Table Space of the Database Is Normal
[Maintenance tool]
Acquire the table space (including configuration, alarm and performance) use information with the
database monitoring module in the OMCR (V2) client system tools.
[Test procedure]
1. Enter the OMCR (V2) main interface.
2. Select [System Tools→Database Configuration and Monitoring] to enter the database monitoring
information interface.
3. On the database monitoring information interface, observe the total space of the database and the
space used by each database. For details, please refer to ZXG10-BSS (V2) Base Station
Subsystem Operation Manual.
[Normal result]
No alarm related to insufficient database table space is reported.
Generally, it is required that the free space of the database is 15% more than the total space.
[Troubleshooting]
Please collate the data if any alarm related to insufficient database table space is detected or you find
112
that the free space of the database is 15% lower than the total space. Note that the data of at least one
month should be reserved in the database. If necessary, you can expand the database table space.
1.15 Checking SS7 Link Running Status of the Central Module
[Maintenance tool]
Observe the status of dynamic data management and indicators on the COMM (MTP2) panel at the
OMCR (V2) client.
[Test procedure]
2. Select [Configuration Management→Dynamic Data Management] to enter the dynamic data
management interface.
3. Expand [ZTE Corporation→Network Management Domain→GSM Device Selection→BTS
Device→n7link].
4. Select the n7link to be observed. You can check the working status of the SS7 link through the pull-
down or right-click menu.
[Normal result]
1. The green HL1 indicator on the COMM (MTP2) board flashes quickly.
113
2. All A interface trunk circuits in dynamic data management are running normally (except
manually blocked or connectionless A interfaces).
3. In dynamic data management, the status of all SS7 links is normal.
[Troubleshooting]
If the link is in the inactive status, please run the “Activate” command to try to activate this n7link.
1.16 Checking Running Status of Each Module’s LapD Link
[Maintenance tool]
Observe the status of the dynamic data management, alarm management and COMM (LapD) panel
indicators at the OMCR (V2) client.
[Test procedure]
1. Enter the OMCR (V2) main interface. Then, select [Configuration Management→Dynamic Data
Management] to enter the dynamic data management interface.
2. Expand [ZTE Corporation→Network Management Domain→GSM Device Selection→BTS
Device→LapD Rack ID to Be Observed→LapD Shelf ID to Be Observed→LapD Slot ID to Be
Observed→LapD] successively.
3. Select the LapD link to be observed. Then, you can check the running status of the LapD link
114
through the pull-down or right-click menu.
[Normal result]
1. The green HL1 indicator on the COMM (LapD) board flashes slowly.
2. All Abis interface circuits in the OMCR (V2)dynamic data management are normal (except the
manually blocked and connectionless Abis interfaces).
[Troubleshooting]
1. If the corresponding LapD is blocked, please check whether the corresponding BTS device has been
powered on.
2. If the BTS device has been powered on, please check whether the related data configuration is correct.
3. Check whether the corresponding GIPP and TIC boards are running normally.
4. Check whether the transmission is normal.
1.17 Checking Frame Relay Running Status of the Gb Interface
[Maintenance tool]
Observe the status of the dynamic data management and related panel indicators at the OMCR (V2)
client.
[Test procedure]
115

2. Select [Configuration Management→Dynamic Data Management] to enter the dynamic data
management interface.
3. Expand [ZTE Corporation→Network Management Domain→GSM Device→BTS Device→NSVCI].
Then, you can see the configured NSVC link in the main window.
4. Select the NSVC link to be observed. Then, you can check the running status of the NSVC link
through the pull-down or right-click menu.
[Normal result]
1. The RUN indicators of the FRP, BRP and PUC boards in SPCU as well as the GIPP and TIC
boards in GIU are all normal.
2. All Gb interface circuits in the OMCR (V2) dynamic data management are normal ( except the
manually blocked and connectionless Gb interfaces).
[Troubleshooting]
1. It the link status is manually blocked, please try to unblock it manually.
2. If the link fails, please check in the following sequence:
1) Check whether each board is running normally.
2) Check whether the E1 connection is correct.
3) Check whether NSVC can be successfully reset.
116
4) Check whether the configuration at the BSC is consistent with that at the SGSN.
1.18 Duty Log
A duty log is a work summary for a day on duty.

It records in detail the system's daily running status, version status, data modification, upgrade,
description of pending faults left over by the last shift and handling of them, and the description of faults
detected at the current shift and handling of them. Especially the detailed description of pending faults
of the current shift, such as the fault severity and solution degree, is provided for analysis and handling
of any occurring problem. In addition, the duty log also contains the shift relief record to distinguish
between different responsibilities.
117
Chapter 2 Weekly Routine Maintenance
The weekly routine maintenance items of the BSC (V2) equipment are shown in the following table:

Please refer
Environment monitoring
Equipment cleanness to Section
maintenance check
2.1.
Please refer
Viewing busy-hour MP load to Section
2.2.
Communication between MP and each PP Please refer to
unit Section 2.3 .
Main equipment running status Please refer to
Backing up ZDB of all foreground modules
maintenance check Section 2.4 .
Please refer to
Analyzing history alarms of the past week
Section 2.5 .
Analyzing daily performance reports of the Please refer

to Section
past week
2.6.
119
Please refer
Backing up configuration data to Section
2.7.
Database maintenance check Please refer to
Querying and deleting alarm and
Section 2.8
performance data
and 2.9 .
Please refer to
Other maintenance items Antivirus of client computer
Section 2.10 .
Checking tool instruments and Please refer to
documentation Section 2.11 .
2.1 Equipment Cleanness
[Maintenance tool] Cleaning cloth.

[Test procedure] Check whether there is any spider web or visible dust coverage on the equipment shell,
within the equipment or on the floor, computer and maintenance desktop in the equipment room.
[Normal result] The equipment room should be clean and free from any visible dust accumulation.
120
[Troubleshooting] Clean the equipment room.
2.2 Viewing Busy-hour MP Load
[Maintenance tool] Create a measurement job for testing the MP load. Generally, such a measurement
job does not exist by default.
[Test procedure]
1. Create a measurement job for testing the MP load. For details, please refer to ZXG10-BSS (V2)
Base Station Subsystem Operation Manual.
2. View the MP load data when there is data report from the created measurement job.
[Normal result] The MP load data can be viewed.
[Troubleshooting] If both the peak and average values of the MP’s CPU load are quite high in busy
hours, it indicates that the system is overload in busy hours. In this case, please consider of system
network adjustment and expansion.
2.3 Checking Communication between MP and Each PP Unit
[Maintenance tool]
121
Observe the status of the running indicator on the panel and the background alarms to judge the running
status of the central module and peripheral modules as well as whether the communication between the
central module and each peripheral module is normal.
[Test procedure]
1. Observe whether the running indicator on the COMM (MPPP) board is normal.
2. Check whether any alarm about communication between the MP and each PP unit is reported
through alarm management of OMCR (V2).
[Normal result]
1. The running indicator on the COMM (MPPP) board is normal.
2. No alarm about communication between the MP and each PP unit is detected at the OMCR (V2)
alarm console.
[Troubleshooting]
Please refer to the part describing how to handle the alarm about communication between the MP and
each PP unit.
2.4 Backing up ZDB of All Foreground Modules
[Maintenance tool]
122
OMCR (V2) provides a special tool “omcftp” for backup.
The “omcftp” tool is a “ftpclient” process running in the sever, which is used to transfer files between
the MP and server and perform other file directory operations. It needs no parameter in running. Its
running mode and command usage are basically the same as the standard “ftp”.
The usage of common “omcftp” commands are shown in the following table.
Command Meaning
help, ? To list available commands if no parameter is carried and explain the
related command if a parameter is carried
connect bscid.moduleno. To connect with the specified MP. Here, “0” represents the left MP; “1”
{0|1|2|3} represents the right MP; “2” represents the active MP; while “3”
represents the standby MP. In addition, the “bscid” and “moduleno”
configuration should be consistent with that in “bsccfg.ini”.
cd To perform operations on the remote directory
lcd To perform operations on the local directory
dir, ls To list contents in the remote current directory
get filename To fetch a file from the MP to the local current directory. A precise file
name should be specified.
123
Command Meaning
put filename To send a file from the hard disk to the current directory of the MP. A
precise file name should be specified.
mget filename To fetch multiple files form the MP to the hard disk. Wildcard is
supported in the file names. However, in the NT version, only the
following forms are supported: file.*, *.ext and *.*.
mput filename To send multiple files from the hard disk to the MP. Wildcard is
supported in the file names. However, in the NT version, only the
following forms are supported: file.*, *.ext and *.*.
close To close the current connection
rmfile filename To delete the remote file and directory. The precise file name and
directory name should be specified.
mkdir dirname To create a remote directory
pwd To display the remote current directory
rename To rename a file
prompt A prompt switch. If prompt=on, users will be prompted to confirm the
operation when deleting or extracting a file; if prompt=off, users will
124
Command Meaning
not be prompted to confirm the operation when deleting or extracting a
file.
bye To exit omcftp
[Test procedure]
1. Connect to the BSC MP and the corresponding MP (connect to the active MP in the central
module of BSC1 for instance).
bash-2.02$ omcftp
ftp>connect 1.1.2
MP 1.1.2 connected
2. Turn to the directory where the ZDB file is located.
ftp>cd /data/work
CD Command Successful.
 Tips: The foreground ZDB files are placed under the MP's “/data/work/”. The ZDB file of the
central module is different from that of a peripheral module. They should be backed up separately. The
print files are placed under the MP’s “/trace/” directory, including the log file per day, the poweron.LOG
file, INT13.LOG file, ERROR.LOG file and so on.
125
3. Modify the prompt attribute.
ftp>prompt
Prompt Off
 Tips: This step is not compulsory.
4. Extract the ZDB files.
ftp>mget *.*
5. Extract other files according to the above steps, such as print files.
6. Exit omcftp.
ftp>bye
[Precautions]
The backup files are saved under the current directory, that is, the current directory during omcftp
running. After omcftp running, you can also run the “lcd” command to change the current directory of
the server, such as “lcd /export/home/omc/” (the current directory of the server is changed to
“/export/home/omc/”).
126
2.5 Analyzing History Alarms of the Past Week
[Maintenance tool] Summarize and classify history alarms of the past week. The emphasis of analysis
should be put on alarms occurring frequently.
[Test procedure] Please refer to ZXG10-BSS Base Station Subsystem Operation Manual.
[Troubleshooting] Observe alarms frequently occurring in the past week and put emphasis on analysis
of these alarms. In addition, locate faults according to the actual situation.
2.6 Analyzing Daily Performance Reports of the Past Week
[Maintenance tool]
Create a weekly performance report through the performance management part of the OMCR (V2)
client. Then, perform analysis on the report indexes by graphic means.
[Test procedure]
1. Create a weekly performance report of the past week. For details, please refer to ZXG10-BSS
127
2. Perform graphic analysis on the weekly performance report. For details, please refer to ZXG10-
BSS Base Station Subsystem Operation Manual.
[Troubleshooting]
All indexes of the performance report are normal in the graphic analysis result.
2.7 Data Backup
Database backup and recovery is one of the basic tasks for database maintenance personnel. In case a
database is damaged or lost due to some accident, the backup data can be used to recover this database.
Periodic database backup is required to reduce the data loss to the minimum degree during data recovery
in case of system media faults and errors.
2.7.1 Backing up Configuration Data

[Maintenance tool]
Back up the database via the OMCR (V2) client or with the tools provided by OMCR (V2). Generally,
the OMCR (V2) client is recommended.
[Test procedure]
1. Back up the configuration database via the OMCR (V2) client.
128
For how to back up the configuration database via the OMCR (V2) client, please refer to “How to Back
up Data in Database” as described in ZXG10-BSS (V2) Base Station Subsystem Operation Manual.
2. Back up the configuration database with the tools provided by OMCR (V2).
1) Oracle database
The following files are involved in Oracle configuration database backup with the tools provided by
OMCR (V2):
cmexp: Is the logic backup script of configuration data.
exparam.dat: Is a parameter file used in combination with cmexp, which is used to specify the
destination file for backup.
These two files are generally placed under the “$OMCHOME/omc/tools/dbbak/” directory of the server.
During execution of the “cmexp script”, read the parameter file “exparam.dat”. After the execution is
completed, the “dmp” file (dump file) and cmexp.log (log file) will be generated.
Then procedures of configuration data backup are as follows:
 Use the “vi” tool to modify “exparam.dat”. The formats of the first several lines of the “exparam.dat”
file are as follows:

bash-2.03$ vi exparam.dat
FILE=bsc2.dmp
129
ROWS=y
LOG=bsc2.log
DIRECT=n
CONSTRAINTS=n
Specify a destination file for backup (that is, a “dmp” file) in the FILE field. Users can use “vi” to edit
this file. It can be modified to the following form: FILE=/export/home/omc/omcbak/cm0920.dmp, that
is, generating a specified file “cm0920.dmp” on the specified path “/export/home/omc/omcbak/”. If no
path is specified, this specified file will be generated under the current directory. If the file specified by
FILE already exists, the new backup file will overwrite the original one.
Specify the log file for backup in the LOG field. The generated log file is under the current directory.
 Run “cmexp”. For example:

bash-2.03$ cmexp username/password
2) Db2 database
The file involved in Db2 configuration database backup with the tools provided by OMCR (V2) is as
follows:
cmexp.sh: Is the logic backup script of configuration data.
130
This file is generally placed under the “$OMCHOME/omc/db2tools/dbbak/” of the server.
After execution of the “cmexp.sh” script, a “tar” file will be generated (packaged dump file).
The procedures of configuration data backup are as follows:
 Use the “vi” tool to modify “cmexp.sh”.

bash-2.03$ vi cmexp.sh
The formats of the first several lines of the “cmexp.sh” file are as follows:
#! /bin/sh
#config information
EXPFILE=cmbak.tar
Specify a destination file for backup (that is, the “tar” file) in the EXPFILE field. Users can use “vi” to
edit this file. It can be modified to the following form: FILE=/export/home/omc/omcbak/cm0920.tar,
that is, generating a specified file “cm0920.tar” on the specified path “/export/home/omc/omcbak/”. If
no path is specified, this specified file will be generated under the current directory. If the file specified
by FILE already exists, the new backup file will overwrite the original one.
131
 Run “cmexp.sh”.
bash-2.03$cmexp.sh
Note: Since database configuration and connection have set in “dbcfg.ini”, please ensure
that the configuration of the OMCR (V2) system is normal before running the backup
script (for instance, the OMCHOME environment variable has been set and the
“dbcfg.ini” configuration is correct). In the meantime, users have the authorities for
“cmexp.sh” execution.
[Normal result]
The configuration database backup file is generated under the specified directory.
[Troubleshooting]
View the configuration export log to analyze whether the cause is that the user name is incorrect, no path
can be found or the corresponding table does not exist in the database.
[Precautions]
To reduce the influence on the system as best as possible, the database backup should be performed
when the traffic is low.
Please back up data in advance whenever it is necessary to modify data. In addition, please back up data
again after data modification.
132
2.7.2 Backing up Alarm Data

[Maintenance tool]
You can back up the database either via the OMCR (V2) client or with the tools provided by OMCR
(V2). Generally, the OMCR (V2) client is recommended.
[Test procedure]
1. Back up the alarm database via the OMCR (V2) client.
For how to back up the alarm database via the OMCR (V2) client, please refer to “How to Back up Data
in Database” as described in ZXG10-BSS (V2) Base Station Subsystem Operation Manual.
2. Back up the alarm database with the tools provided by OMCR (V2).
1) Oracle database
For the Oracle database, backup of the alarm data is the same as that of the configuration database.
Please refer to the description about configuration data backup in the Oracle database.
The backup script and parameter file of the alarm data are placed under the
“$OMCHOME/omc/tools/dbbak/” directory. The script name is “fmexp” and the read parameter file is
“fmexp.dat”.
133
2) Db2 database
For the Db2 database, backup of the alarm data is the same as that of the configuration database. Please
refers to the description about configuration data backup in the Db2 database.
The backup script of the alarm data is placed under the “$OMCHOME/omc/db2tools/dbbak/” directory.
The script name is “fmexp.sh”.
[Normal result]
The backup file of the alarm database is generated under the specified directory.
134
2.7.3 Backing up Performance Data
[Maintenance tool]
You can back up the database either via the OMCR (V2) client or with the tools provided by OMCR
(V2). Generally, the OMCR (V2) client is recommended.
[Test procedure]
1. Back up the performance database via the OMCR (V2) client.
For how to back up the performance database via the OMCR (V2) client, please refer to “How to Back
up Data in Database” as described in ZXG10-BSS (V2) Base Station Subsystem Operation Manual.
2. Back up the performance database with the tools provided by OMCR (V2).
1) Oracle database
For the Oracle database, backup of the performance data is the same as that of the configuration data.
Please refer to the description about configuration data backup in the Oracle database.
The backup script and parameter file of the performance data are placed under the
“$OMCHOME/omc/tools/dbbak/” directory. The script name is “pmexp” and the read parameter file is
“pmexp.dat”.
135
2) Db2 database
For the Db2 database, backup of the performance data is the same as that of the configuration data.
Please refer to the description about configuration data backup in the Db2 database.
The backup script of the performance data is placed under the “$OMCHOME/omc/db2tools/dbbak”
directory. The script name is “pmexp.sh”.
[Normal result]
The performance database backup file is generated under the specified directory.
[Troubleshooting]
None.
136
2.8 Alarm and Performance Data Query
During system running, records in the database will be increased incessantly and the database will be
enlarged gradually. To ensure effective utilization of the disk space, it is necessary to periodically check
and collate the database space, especially the alarm database and performance database. Otherwise, too
much data may lead to slow or abnormal running of the system.
2.8.1 Alarm Data Query
[Maintenance tool]
The alarm data can be queried either via the OMCR (V2) client or with the tools provided by OMCR
(V2). Generally, the OMCR (V2) client is recommended. .
[Test procedure]
1. Query the via the alarm database via the OMCR (V2) client.
For how to query the alarm database via the OMCR (V2) client, please refer to the parts related to alarm
view as described in ZXG10-BSS (V2) Base Station Subsystem Operation Manual, such as “How to
Query Alarms by Conditions”.
137
2. Query the via the alarm database with the tools provided by OMCR (V2) alarm database.
1)Oracle database
 Connect the Oracle database.
For how to log in to the Oracle database, please refer to “How to Log in to Oracle Database” in Oracle
server maintenance experiences as described in ZXG10-BSS (V2) Base Station Subsystem Operation
Manual.
After database connection, perform database query operation under the “sqlplus” prompter as required.
 Query alarm data.
View alarms in the database:

sqlplus>select count(*) from falarminfo;
The returned data is the number of all alarms in the database.
View the earliest alarm report time:
sqlplus>select to_char(min(reporttime),'yyyymmddhh24miss') from falarminfo;

The returned time format is: yyyymmddhh24miss
138
Here: “yyyy” is a 4-digit year, such as 2001.
mm: Is a 2-digit month, such as 09.
dd: Is a 2-digit date, such as 19.
hh24: Is a 2-digit hour 24-hour system), such as 23.
mi: Is a 2-digit minute, such as 30.
ss: Is a 2-digit second, such as 50.
View the quantity of alarms corresponding to each alarm code in the current database to determine the
alarm distribution:
sqlplus>select code,count(*) from falarminfo group by code;
2) Db2 database
 Connect the Db2 database.

For how to log in to the Db2 database, please refer to “How to Log in to Db2 Database” in Db2 server
maintenance experiences as described in ZXG10-BSS (V2) Base Station Subsystem Operation Manual.
After database connection, perform database query operation under the “db2” prompter as required.
 Query alarm data.
139
View alarms in the database:

db2 => select count(*) from falarminfo
The returned data is the number of all alarms in the database.
View the earliest alarm report time:
db2 => select tochar(min(reporttime),'yyyymmddhh24miss') from falarminfo

The returned time format is: yyyymmddhh24miss
Here: “yyyy” is a 4-digit year, such as 2001.
mm: Is a 2-digit month, such as 09.
dd: Is a 2-digit date, such as 19.
hh24: Is a 2-digit hour 24-hour system), such as 23.
mi: Is a 2-digit minute, such as 30.
ss: Is a 2-digit second, such as 50.
View the quantity of alarms corresponding to each alarm code in the current database to
determine the alarm distribution:
db2 => select code,count(*) from falarminfo group by code
140
Note: Please do not input “;” at the end of a command line under the “db2” prompter.
[Normal result]
Alarms meeting the conditions can be viewed.
[Troubleshooting]
1. Check whether the connection between the BSC and server is normal.
2. Check whether the link between the client and server is normal.
141
2.8.2 Performance Data Query

[Maintenance tool]
The performance data can be queried with the tools provided by OMCR (V2).
[Test procedure]
1. Oracle database
1) Connect the Oracle database.
For how to log in to the Oracle database, please refer to “How to Log in to Oracle Database” in Oracle
server maintenance experiences as described in ZXG10-BSS (V2) Base Station Subsystem Operation
Manual.
After database connection, perform performance database query operation under the “sqlplus” prompter
as required.
2) View the performance data.
 View the performance data volume in the basic measurement table.

sqlplus>select count(*) from pbasicm;
..........View the earliest performance data in the database.
142
sqlplus>select to_char(min(recorddatatime),'yyyymmddhh24miss') from pbasicm;
Return the earliest time of performance data in the database.
2. Db2 database
1) Connect the Db2 database.
For how to log in to the Db2 database, please refer to “How to Log in to Db2 Database” in Db2 server
maintenance experiences as described in ZXG10-BSS (V2) Base Station Subsystem Operation
Manual.
After database connection, perform performance database query operation under the “db2” prompter
as required.
2) View the performance data.
View the performance data volume in the basic measurement table.

db2 => select count(*) from pbasicm
View the earliest performance data in the database.
db2 =>select tochar(min(recorddatatime),'yyyymmddhh24miss') from pbasicm
Return the earliest time of performance data in the database.
[Normal result] Performance data meeting the conditions can be viewed.
[Troubleshooting]
143
1. Check whether the connection between the BSC and server is normal.
2. Check whether the link between the client and server is normal.
2.9 Alarm and Performance Data Deletion
2.9.1 Alarm Data Deletion
[Maintenance tool]
The alarm database can be deleted either via the OMCR (V2) client or with the tools provided by
OMCR (V2). Generally, the OMCR (V2) client is recommended.
[Test procedure]
1. Delete alarm data via the OMCR (V2) client.
You can set automatic alarm data deletion via parameter setting by referring to “How to Set
Periodic and Automatic Alarm Dump” as described in ZXG10-BSS (V2) Base Station Subsystem
Operation Manual.
2. Delete alarm data with the tools provided by OMCR (V2).
144
1) Oracle database
For how to log in to the Oracle database, please refer to “How to Log in to Oracle Database”
in Oracle server maintenance experiences as described in ZXG10-BSS (V2) Base Station
After database connection, perform database deletion operation under the “sqlplus” prompter
as required.
 Delete old alarm data.
After viewing the earliest alarm report time, you can delete data before a certain moment in
the following way (take deletion of data with the alarm report time before August 30, 2001 for
example):
sqlplus>delete from falarminfo where to_char(reporttime, 'yyyymmdd') <'20010830';
sqlplus>commit;
In the specific operating process, the database deletion always fails if the alarm data volume is
very high. In this case, the selected data can be deleted in different segments. Generally, a safe
145
way is to delete data every two days. The specific deletion statement is as follows:
Delete all alarms between 2001-08-10 ---- 2001-08-12:
delete from falarminfo where to_char(reporttime,'yyyymmdd')>'20010810' and
to_char(reporttime,'yyyymmdd')<'20010812';
commit;
Delete all alarm data records between 2001-08-12 ---- 2001-08-14:
commit;

commit;
2) Db2 database

For how to log in to the Db2 database, please refer to “How to Log in to Db2 Database” in
146
server maintenance experiences as described in ZXG10-BSS (V2) Base Station Subsystem
Operation Manual.
After database connection, perform alarm database deletion operation under the Db2 prompter
as required.
 Delete alarm data.
After viewing the earliest alarm report time, you can delete data before a certain moment in
the following way (take deletion of data with the alarm report time before August 30, 2001 for
example):
db2=>delete from falarminfo where tochar(reporttime, 'yyyymmdd') <'20010830'
db2 => commit
In the specific operating process, the database deletion always fails if the alarm data volume is
very high. In this case, the selected data can be deleted in different segments. Generally, a safe
way is to delete data every two days. The specific deletion statement is as follows:
Delete all alarms between 2001-08-10 ---- 2001-08-12:
delete from falarminfo where tochar(reporttime,'yyyymmdd')>'20010810' and

tochar(reporttime,'yyyymmdd')<'20010812'
147
commit

commit

commit
[Normal result] Alarm data within the specified time segment are deleted.
[Troubleshooting] None.
[Precautions]
Data in the alarm database should be cleared every month after backup of the alarm database.
When clearing the alarm database, please clear data older than two months each time, that is, ensuring
two months of data are reserved in the database. The time for reserving data in the database is only a
recommended value, which can be flexibly determined according to the site situation. However, it
148
should be not less than one month. For example, if many SITEs are connected at the time of
deployment, the data reservation time can be set shorter. However, the shortest time should be not less
than one month. If fewer SITEs are connected at the time of deployment, the data reservation time can
be set longer.
Due to reasons like that deletion of alarm data records may take a lot of time, it is recommended to
delete records within a shorter period each time. Please determine it according to the network scale and
its does not exceed 15 days generally.
149
2.9.2 Performance Data Deletion

[Maintenance tool]
The performance database can be deleted either via the OMCR (V2) client or with the tools provided by
OMCR (V2). Generally, the OMCR (V2) client is recommended.
[Test procedure]
1. Delete the performance database via the OMCR (V2) client.
You can set automatic performance data deletion via parameter setting by referring to “How to Set
Periodic and Automatic Performance Data Dump” as described in ZXG10-BSS (V2) Base Station
2. Delete the performance database with the tools provided by OMCR (V2).
1) Oracle database
For how to log in to the Oracle database, please refer to “How to Log in to Oracle Database”
in Oracle server maintenance experiences as described in ZXG10-BSS (V2) Base Station
150
After database connection, perform database deletion operation under the “sqlplus” prompter
as required.
 Delete old performance data.
After viewing the earliest performance report time, you can delete data before a certain
moment in the following way:
Delete data with the record time before August 30, 2001. A command example is as follows:
sqlplus>delete from pbasicm where to_char(recorddatatime, 'yyyymmdd') <'20010830';

sqlplus>commit;
In the specific operating process, the database deletion always fails if the performance data
volume is very high. In this case, the selected data can be deleted in different segments.
Generally, a safe way is to delete data every two days. The specific deletion statement is as
follows:
Delete all performance data records between 2001-08-10 ---- 2001-08-12:
151
delete from pbasicm where to_char(recorddatatime,'yyyymmdd')>'20010810' and

to_char(recorddatatime,'yyyymmdd')<'20010812';
commit;

commit;

commit;
2) Db2 database
For how to log in to the Db2 database, please refer to “How to Log in to Db2 Database” in
152
server maintenance experiences as described in ZXG10-BSS (V2) Base Station Subsystem
Operation Manual.
After database connection, perform performance database deletion operation under the Db2
prompter as required.
 Delete performance data.
After viewing the earliest performance report time, you can delete data before a certain
moment in the following way:
Delete data with the record time before August 30, 2001. A command example is as follows:
db2 => delete from pbasicm where tochar(recorddatatime, 'yyyymmdd') <'20010830'

db2 => commit
In the specific operating process, the database deletion always fails if the performance data
volume is very high. In this case, the selected data can be deleted in different segments.
Generally, a safe way is to delete data every two days. The specific deletion statement is as
follows:
153
delete from pbasicm where tochar(recorddatatime,'yyyymmdd')>'20010810' and

tochar(recorddatatime,'yyyymmdd')<'20010812'
commit
Delete all performance data records between 2001-08-12 ---- 2001-08-14 :

commit

commit
[Normal result] The performance data within the specified time segment are deleted.
[Precautions]
154
Data in the performance database should be cleared every month after backup of the database.
When clearing the performance database, please clear data older than two months each time, that is,
ensuring two months of data are reserved in the database. The time for reserving data in the database is
only a recommended value, which can be flexibly determined according to the site situation. However, it
should be not less than one month. For example, if many SITEs are connected at the time of
deployment, the data reservation time can be set shorter. However, the shortest time should be not less
than one month. If fewer SITEs are connected at the time of deployment, the data reservation time can
be set longer.
2.10 Antivirus of Server and Client Computers
[Maintenance tool]
Update the virus library periodically. You can run “LiveUpdate” of Norton Antivirus to download the
latest virus definition from the corresponding website.
[Test procedure]
1. Run the server and client to install the Norton antivirus software. Enable the real-time scanning
(auto protection) function. According to the actual situation, set the real-time scanning time to a
period when the telecom operator’s traffic is idle, thus avoiding any influence on the background
155
service.
2. Periodically update the virus library. Run “LiveUpdate” of Norton Antivirus to download the latest
virus definition from the corresponding website to avoid any damage to the PC caused by new
viruses.
[Normal result]
The virus library update is completed.
[Troubleshooting]
None.
2.11 Checking Tool Instruments and Documentation
[Maintenance tool]
Check whether the common tools, instruments and documentation are complete and accurate in the
equipment room.
[Test procedure]
1. Check whether the common tools and instruments are complete in the equipment room.
2. Check the instruments to ensure their accuracy.
3. Check whether the delivery-attached documentation is complete in the equipment room.
156
[Normal result]
The common tools, instruments and documentation are complete and accurate in the equipment room.
The common tools in the equipment room include the compass, telescope, digital camera, GPS
instrument, test MS, antenna feeder tester, power meter, field strength tester, spectrometer (or special
network optimization instrument like the drive test device).
The common tools include the electric percussion drill, screwdriver (straight and cross), nippers, pliers
(sharp-nose pliers, diagonal pliers and pincer pliers), spanner, tape, electric iron (including antistatic
electric iron), antistatic wrist strap, multimeter, horizontal ruler, plumb, safety helmet, slip-proof gloves
and so on.
[Troubleshooting]
If the common tools, instruments and documentation in the equipment room are incomplete, please
apply for configuration in time. In addition, if any common instrument is inaccurate, please report for
repair in time.
157
Chapter 3 Monthly Routine Maintenance
The monthly routine maintenance items of the BSC (V2) equipment are shown in the following table:

Please refer
Performing statistics and analysis on all history
to Section
alarms in the past month
3.1.
Please refer
Performing statistics and analysis on all daily
to Section
performance reports in the past month
Main equipment running 3.2.
status maintenance check Please refer

Service dialing test to Section
3.3.
Please refer
Fetch and print foreground INT13 or
to Section
ERROR.LOG
3.4.
159
Please refer
Backing up alarm data to Section
3.5.
Please refer
OMC maintenance check Backing up and deleting old logs to Section

3.6.
Please refer
Performing secondary backup on backup data of
to Section
this month from the server to other storage media
3.7.
Other maintenance items Please refer

Checking whether the alarm box is running
to Section
normally
3.8.
Checking spare parts Please refer
to Section
3.9.
160

Please refer
Scanning viruses for the client computer to Section
3.10.
3.1 Performing Statistics and Analysis on All History Alarms in the Past
Month
[Maintenance tool] Summarize and classify history alarms of the past month. The emphasis of analysis
should be put on alarms occurring frequently.
[Test procedure] Please refer to ZXG10-BSS Base Station Subsystem Operation Manual.
[Troubleshooting] Observe alarms frequently occurring in the past month and put emphasis on
analysis of these alarms. In addition, locate faults according to the actual situation.
3.2 Performing Statistics and Analysis on All Daily Performance

Reports in the Past Month
[Maintenance tool]
Create a monthly performance report through the performance management part of the OMCR (V2)
161
client. Then, perform analysis on the report indexes by graphic means.

[Test procedure]
1. Create a monthly performance report of the past month. For details, please refer to ZXG10-BSS
2. Perform graphic analysis on the monthly performance report. For details, please refer to ZXG10-
BSS Base Station Subsystem Operation Manual.
[Troubleshooting]
All indexes of the performance report are normal in the graphic analysis result.
3.3 Service Dialing Test
3.3.1 Voice Service Dialing Test

[Maintenance tool]
Dialing test
[Test procedure]
1. A local MS subscriber calls a local PSTN subscriber (replaceable with dialing between two local
MSs).
162
1) A local MS subscriber calls an idle local PSTN subscriber and the called party answers.
2) A local MS subscriber calls an idle local PSTN subscriber and the caller hooks on.
2. A local PSTN subscriber calls a local MS subscriber (replaceable with dialing between two local
MSs).
1) A local PSTN subscriber calls an idle local MS subscriber and called party answers.
2) A local PSTN subscriber calls a local MS subscriber but the called party is busy.
3) A local PSTN subscriber calls an idle local MS subscriber but the MS does not answer.
[Normal result]
1. A local MS subscriber calls a local PSTN subscriber:
1) A local MS subscriber calls an idle local PSTN subscriber and the called party answers to complete
the call. In this case, the conversation should be stable. When the PSTN subscriber hooks on, the MS
subscriber should be able to correctly release this call and the related resources.
2) An idle local PSTN subscriber is called. When the called party rings and the caller hears the ringback
tone, the calling MS hooks on. In this case, this call and the related resources should be correctly
released.
2. A local PSTN subscriber calls a local MS subscriber:

163
1) A local PSTN subscriber calls a local MS subscriber and the called party (MS) answers to complete
the call. In this case, the conversation should be stable. When the PSTN subscriber hooks on, the MS
subscriber should be able to release this call and the related resources.
2) A local PSTN subscriber calls a local MS subscriber but the called party is busy. In this case, the call
should be normally released.
3) A local PSTN subscriber calls a local MS subscriber but the MS does not answer. In this case, the call
should be normally released.
[Troubleshooting]
Comprehensive analysis and processing are performed according to the background alarms, performance
report and signaling.
3.3.2 Test on GPRS Service Functions
The GPRS service function tests are to test the borne GPRS service capabilities, including ping, ftp,
www, wap and so on.
1. Ping service
1) Test objective
Check whether the ping to the data transmission bottom layer provided by the GPRS system is
successful and whether the bottom layer is stable.
2) Test procedure
164
Start the ping network detection program in the PC connected with an MS to detect a network
connection with a known address (the ping option can be set to “-w 8000” and the packet length
can be 20, 80 or 100).
3) Normal result
The ping succeeds and the connection with this address can be set up. The ping time at www is
between 1000 ms ~6000ms. The ping is continuous with few packet drop or interruption.
4) Troubleshooting
 Ensure that the MS supports GPRS and the GPRS service has been enabled in the SIM card.
 Ensure that the MS’s APN configuration is correct.
 Confirm that the MS’s PDP has been successfully activated.
 Confirm that both the status of each channel and that of the cell are normal.
 Reset the corresponding BRP board.
 Reset the corresponding FRP board.
2. www service
1) Test objective: To check the www browse service availability of the GPRS system and the
system stability.
2) Test procedure
Start IE in the PC connected with GPRSMS to browse www webpages, such as Http://www.sina.
165
com.cn/. Enable multiple page links and continue with the webpage browse for a period of time.
3) Normal result
The www homepage can be opened. The speed of browsing multiple pages is tolerable. The
receiving and transmitting data rates observed in the system monitor are expected values.
4) Troubleshooting
166
3. ftp service
1) Test objective
To check the file transfer ftp rate and performance provided by the GPRS system.
2) Test procedure
In the PC connected with GPRSMS, perform ftp file upload and download operations on the PC
or Intranet server providing ftp over www. For example, for files provided at
http://www.download.com.cn/, check whether they can be downloaded smoothly and
successfully. Please check whether the MS is offline sometimes and whether the transmission is
interrupted.
3) Normal result
The files can be successfully downloaded.
4) Troubleshooting
167
4. wap service
1) Test objective
Check the performance of wap browse provided by the GPRS system.
2) Test procedure
 Use the MS’s “wap over GPRS” function to activate PDP and then browse wap websites,
such as http://wap.sina.com.cn.
 Browse multiple wap webpages to check whether you can normally browse them.
3) Troubleshooting
3.4 Fetching Log Files from the Foreground
[Maintenance tool]
168
Check whether any files related to the last check exist in the “/Trace” directory of the active/standby MP.
If there is any, please fetch them with the “omcftp” tool for analysis.
[Test procedure]
For the specific operation, please refer to “Backing up ZDB of All Foreground Modules” as described in
ZXG10-BSS (V2) Base Station Subsystem Operation Manual.
[Normal result]
The foreground INT13.LOG, ERROR.LOG and POWERON.LOG files and the daily LOG file can be
fetched.
[Troubleshooting]
1. Check whether the OMCR process is normal with the “omcps” tool.
2. Check whether the link between the server and MP is normal.
[Precautions]
The foreground print log is an important tool to analyze, resolve and prevent problems. If a message of
“errorF: receive SABME in Mulframe or TimerRec” appears frequently at a site in peripheral modules,
it indicates that the transmission of this site is unstable and it is necessary to check the transmission.
The foreground print log is generally placed in “C:/TRACE/WEEK*”, which will be saved for one
week. Within 24 hours of a day, 24 log files will be generated correspondingly, which will be saved in a
directory in Week1~Week7. The directory for saving the logs on Sunday is Week1.
169
There are fewer print logs for the central module MP, whose size is generally several Ks or dozens of
Ks. There are many print logs for peripheral modules, whose size varies with the module capacity
(several hundreds of Ks approximately). Maintenance personnel can analyze them based on the related
information.
3.5 Backing up Alarm Data
1. Oracle database
For the Oracle database, backup of the alarm data is the same as that of the configuration data. For
details, please refer to the parts related to the Oracle database as described in ZXG10-BSS (V2) Base
Station Subsystem Operation Manual.
Both the backup script and parameter file of the alarm data are placed under the
“$OMCHOME/omc/tools/dbbak/” directory. The script name is “fmexp” while the read parameter file
is “fmexp.dat”.
2. Db2 database
For the Db2 database, backup of the alarm data is the same as that of the configuration data. For
170
details, please refer to the parts related to the Db2 database as described in ZXG10-BSS (V2) Base
The backup script of the alarm data is placed under the “$OMCHOME/omc/db2tools/dbbak/”
directory. The script name is “fmexp.sh”.
3.6 Backing up and Deleting Old Logs
[Maintenance tool]
Operation logs can be backed up and deleted via the OMCR (V2) client interface.
Process log files can be deleted with the “rm” command at the server.
[Test procedure]
1. Back up and delete operation logs.
Please refer to ZXG10-BSS (V2) Base Station Subsystem Operation Manual.
2. Delete all log files (process logs) older than one week.
1) Manual deletion
The following commands are available:
rm –r *.*[0-5].log /*Delete all log files with the last digit of the date being 0~5*/
171
rm –r *.*2.log /*Delete all log files with the last digit of the date being 2 */
rm –r mpcomm.*.log /*Delete all “mpcomm” log files*/
2) Automatic deletion
In the OMCR (V2) system, run “crontab” to set the task of periodically deleting old files to avoid
insufficient disk space. Generally, the set time is one week, that is, the old logs within 7 days are
to be deleted. However, if the onsite office is at a large scale, the process logs generated each day
will take a lot of disk space. When the log space is scarce, you can modify this setting to delete
these files periodically and automatically.
 View the current “crontab” setting. A command example is as follows:
bash-2.02$ crontab -l
The display on the screen is as follows:
0 2 * * * find /export/home/omc/tmp/ftp -mtime 3 -exec rm {} \;
30 2 * * * find /export/home/omc/tmp/log -mtime 7 -exec rm {} \;
The meaning is to delete the ftp files older than 3 days and the log files older than 7 days
periodically.
172
 Change this setting. A command example is as follows:
crontab -e
The editor serving this purpose is “vi”. You just need to change the above 7 days to the
corresponding value. The default editor of Cron is “ed”. To use “vi” in this case, it is necessary
to set the following environment variable: EDITOR=vi.
 View the modified setting. A command example is as follows:
bash-2.02$ crontab –l
[Normal result]
The log backup files are generated and the old log files in the database are deleted. In addition, useless
files under FTP are also deleted.
[Precautions]
Log files are record files generated during OMCR (V2) system running. They reflect system running on
many aspects, such as the database connection and foreground/background link setup, which can help
users observe the system running and diagnose fault.
The name of a log file consists of three parts: the log type, date and “.log”. For example, a log file
173
named “mpcomm.20030317.log” records MP link setup on March 17, 2003.

Log files are saved under “$OMCHOME/tmp/log”. The directory for saving log files can be changed in
the “tracepath” item in “$OMCHOME/conf/syscfg.ini”.
The database logs will increase unlimitedly automatically if they are not cleared. This may lead to
incessant expansion of log files until the log size upper limit is reached. Once the log files overflow, no
new log can be written. In this case, the data in the database cannot be written too and the system cannot
continue running.
Generally, only log files of the latest week are reserved.
174
3.7 Performing Secondary Backup on Backup Data of This Month from

the Server to Other Storage Media
[Maintenance tool]
Use the ftp backup tool, such as “cuteftp”.
[Test procedure]
1. Run the “cuteftp” applications in the client or PC.
2. Input the IP address of the server on the applications interface to log in to the server.
3. Find the backup files of the current month from the server and transfer them to the client or PC in the
ftp mode.
[Normal result] Data can be smoothly dumped.
[Troubleshooting]
If the ftp operation fails, you may fail to log in to the server or the cached directory authority is read-
only.
If you fail to log in to the server, please check whether the network quality is sound and whether the IP
address is correct. If the problem is with the authority, please modify it.
[Precautions]
175
1. The data to be backed up include the configuration data, alarm data, performance data, logs and so on.
2. Generally, other storage media refer to the client or another PC since no tape drive is available on the
site.
3.8 Checking Whether the Alarm Box Is Running Normally
[Maintenance tool]
Make judgment according to panel indicators.
[Test procedure]
Observe the status of indicators on the panel to judge whether the alarm box is running normally.
[Normal result]
The status of indicators on the panel is normal.
[Troubleshooting]
Handle the fault according to usage of the alarm box.
3.9 Checking Spare Parts
[Maintenance tool]
Check whether the spare parts are complete and in sound conditions.
176
[Test procedure]
1. Check the spare part storage and conditions according to the spare part list.
2. The spare parts should be stored separately from the damaged parts replaced during maintenance
and they should be marked differently to distinguish them.
[Normal result]
The spare parts are complete and in sound conditions.
[Troubleshooting]
Please apply for replenish in time when the common spare parts are used up.
177
3.10 Scanning Viruses for the Client and Server Computers
[Maintenance tool]
Install Norton Antivirus for each server and terminal.
[Test procedure]
Run Norton Antivirus to enter <Dispatch>→<Add an Event>→<Dispatch Virus Scanning>→<Add a
User-defined Event>→<Once per Month>→<Time: 3:00; date: 1>→<Finish>. In this way, all hard
disks will be scanned for viruses on the first day per month.
[Normal result]
No virus is detected.
[Troubleshooting]
If any virus is detected, run the antivirus software to kill it. If you cannot kill it, please update your virus
library immediately.
178
Chapter 4 Half-yearly Routine Maintenance
The half-yearly routine maintenance items for the BSC (V2) equipment are shown in the following
table:

Please refer to
Active/standby board changeover
Section 4.1 .
Please refer to
Active/standby board reset
Section 4.2 .
Main equipment running status Please refer to
Network quality test
maintenance check Section 4.3 .
Please refer to
Checking cable connection
Section 4.4 .
Please refer to
Grounding check
Section 4.5 .
NMC maintenance check Checking system clock of the MP, sever Please refer to
and client Section 4.6 .
179
Please refer to
Checking software version and data
Section 4.7.1
configuration
and 4.7.2 .
Backing up configuration data to other Please refer to
storage media Section 4.7.3 .
Please refer to
Deleting all backup data from the server
Section 4.7.4 .
Please refer to
Backing up several major foreground files
Section 4.7.5 .
Please refer to
Checking power equipment running status
Section 4.7.6 .
Check of corollary equipment Checking transmission equipment running Please refer to
running status status Section 4.7.7 .
Please refer to
Checking battery running status
Section 4.7.8 .
180
4.1 Active/Standby Board Reset
[Maintenance tool]
Reset the active/standby board via either the alarm management interface or the active/standby board
reset button.
[Test procedure]
For how to reset the active/standby board via the alarm interface, please refer to ZXG10-BSS (V2) Base
[Normal result]
The board is reset.
[Troubleshooting]
None.
[Precautions]
Please be very careful when resetting the MP or switching network board. No hot backup board allows
reset of the active and standby boards simultaneously. Otherwise, some or all services will be
interrupted.
181
4.2 Active/Standby Board Changeover
[Maintenance tool]
Perform active/standby board changeover via either the alarm management interface or the
active/standby board changeover button.
[Test procedure]
For the details about how to perform active/standby board changeover via the alarm management
interface, please refer to ZXG10-BSS (V2) Base Station Subsystem Operation Manual.
[Normal result]
The active/standby board changeover succeeds.
[Troubleshooting]
None.
[Precautions]
For active/standby changeover of MP, an interval above 6 minutes is required.
182
4.3 Network Quality Test
4.3.1 BTS Cell Coverage Test

[Maintenance tool]
Perform coverage range test on maintained sites according to the coverage range in network planning.
Sites can be divided into three types of areas: Dense areas at urban centers, urban and suburban joint
areas, and rural areas.
[Test procedure]
1. Coverage test on dense areas at urban centers
Detailed test should be performed on the indoor and outdoor coverage for dense areas at urban
centers.
1) Outdoor test: Before the test, please get a map showing the detailed road, communication and
building information and select the test areas and lines (such as major streets, lanes and dense areas)
from this map. Test MSs and vehicles can be adopted as the test measures. Please record the field
strength at each point in detail along the specified lines. In addition, please perform some dialing test to
calculate the call drop ratios and record them on the map.
183
2) Indoor test: Select some points with dense subscribers like some commercial areas, hotels and
stations. Perform field strength test at every floor of each building and record the results.
2. Coverage test on urban and suburban joint areas
For urban and suburban joint areas, the major test object is the outdoor field strength. Please take
the major streets as the test lines and mark the field strength of each point on the map. For indoor
test, please select typical points and compare the results with the corresponding outdoor field
strength.
3. Coverage test on rural areas
For rural areas, the major test object is the outdoor coverage. Please test the field strength along all
directions with the BTS as the center, draw a coverage diagram, and perform dialing test.
[Normal result]
The coverage range complies with the network planning requirements.
[Troubleshooting]
If there are high deviations from the coverage ranges in the network planning, please contact the ZTE
maintenance office in time. In this case, the network parameters need to be adjusted according to the
184
actual measurement data.
185
4.3.2 BTS Cell Call Quality Test
Maintenance personnel can perform the coverage test and the voice quality test simultaneously. The
conversation test records should be continuous and comparable to facilitate understanding of the
network developments.
4.3.3 Handover Test
[Maintenance tool]
Trigger intra-cell and inter-cell handover by all means to observe whether the handover is normal.
[Test procedure]
1. Intra-cell handover
Set up an MS-PSTN call in a cell and then move the MS within this cell to reduce the conversation
quality of the TCH being used by the MS. Then, observe whether the MS can be handed over to
another TCH.
2. Inter-cell handover
The basic method is to set up an MS-PSTN call in a cell and then move the MS to the destination
cell. If it is difficult to trigger handover in this way, you can also adopt other methods, such as
186
directly initiating a handover instruction to the MS through OMCR (V2).
[Normal result] Intra-cell and inter-cell handover can be triggered and no call drop is detected.
4.4 Cable Connection
[Maintenance tool]
Check the cable connection of all equipment such as the BSC (V2) rack, server and maintenance console
by referring to the ZXG10-BSC (V2) Base Station Controller Installation Manual.
[Test procedure]
Please refer to the cable connection part as described in ZXG10-BSC (V2) Base Station Controller
Installation Manual.
[Normal result]
All connections are correct and reliable.
[Troubleshooting]
Refer to the related parts in ZXG10-BSC (V2) Base Station Controller Installation Manual and check
the cable connection again.
187
4.5 Grounding Check
[Maintenance tool]
Clamp-on ground resistance tester
[Test procedure]
1. Clamp the clamp-on ground resistance tester to the equipment’s protection grounding cable.
2. Directly press down the key to read the ground resistance value and save it.
3. Take off the clamp-on ground resistance tester.
[Normal result]
≤1Ω.
If there are other design requirements, please perform the test as required.
[Troubleshooting]
Check whether the contact between the ground resistance tester and the equipment's grounding cable is
in sound conditions.
188
4.6 Checking System Clocks of MP, Server and Client
[Maintenance tool]
Use man-machine commands to check whether the system clocks of the MP, server and client are
accurate and consistent and modify them.
[Test procedure]
1. View MP system time.
Use a man-machine command to view the MP time. The man-machine command format is as
follows:
ESOF : {EBSCID , EBSCNAME} , ModuleNo;
An example of viewing the time of the central module in BSC 1 is as follows:
ESOF:1,1; Take the time of the central module in BSC 1.
For more information, please refer to the online documentation.
2. View client system clock.
The client’s operating system belongs to the Windows series. The time modification is similar to
that of a PC. You can select [My Computer→Control Panel→Date/Time] to query and modify the
current system time.
189
3. View server system clock.
If the server’s operating system belongs to the Windows series, the time modification is similar to
that of a PC. You can select [My Computer→Control Panel→Date/Time] to query and modify the
current time.
If the server’s operating system belongs to the Solaris series, you can query or modify the system
time in the command line mode. If the current system time is 11:30, November 12, 2003, a
command example is as follows:
bash-2.02$date
The time displayed on the screen is 11:30, November 12, 2003.
A command example for modifying the time is as follows:
bash-2.02$ date 111212002003
The system time is set to 12:00, November 12, 2003.
 Tips:
Please note that there is no restriction to users querying system time. However, to modify the system
time, please switch to the “root” user or a user authorized to modify the time/date.
[Normal result]
190
The system clocks of the MP, server and client are accurate and consistent.
[Troubleshooting]
Set the system clocks of the MP, server and client again. Please take care when synchronizing with the
foreground MP time since it may have some influence on the performance data.
4.7 Checking Software Version and Data Configuration
4.7.1 Checking Software Version

[Maintenance tool]
Check whether each board software version in the server, client and MP exists and is correct.
[Test procedure]
1. Check the software version in the OMCR (V2) server.
At the server, run “amp –v” to view the server software version information. For example:
bash-2.02$ amp –v
2.0(build 555-05d+)
2. Check the software version in the OMCR (V2) client.
191
On the OMCR (V2) client main interface, select [Help→About] to view the maintenance console
software version information.
3. Check each board software version in the BSC and BTS at the MP.
For details, please refer to ZXG10-BSS (V2) Base Station Subsystem Operation Manual.
[Normal result]
The displayed version information complies with the actual versions.
[Troubleshooting]
Load any error version again.
For server and client software installation, please refer to ZXG10-BSC (V2) Base Station Controller
Installation Manual (Software).
For how to load each board software version in the BSC and BTS at the MP, please refer to ZXG10-BSS
(V2) Base Station Subsystem Operation Manual.
192
4.7.2 Checking Data Configuration

[Maintenance tool]
Check whether the data configuration of OMCR (V2) is correct.
[Test procedure]
1. Enter [Integrated Configuration Management] of the OMCR (V2) client and click <Modify>.
Select the corresponding BSC to acquire the equipment-related configuration data in OMCR (V2).
Then, check whether the configuration data is consistent with the actual equipment configuration.
2. Check whether the A interface interconnection parameters are consistent with those set at the
MSC.
3. Check the setting of parameters like the carrier frequency, BCCH and TCH configuration, carrier
power value, adjacent handover cell data, handover parameter, uplink/downlink power control. If there
is any hop, please check the hop parameter setting.
4. Check the GPRS data configuration.
1) Confirm that all cells supporting GPRS has been configured with PS channels.
2) Check the BRP configuration: Confirm that the number of cells in each BRP does not exceed 40
and the total number of PS channels (including dynamic channels) in each BRP does not exceed the
193
threshold (at present, the threshold of any version previous to 2.52.00a is 80 and that of 2.52.00a and
any subsequent version is 120).
3) Check the FRP configuration: Check whether the setting of interconnection parameters in FRP like
NSE, NSVC, DLCI and STATUS is consistent with that at the SGSN.
4) Check the GPRS related parameters: Check whether the GPRS cell parameter configuration, such
as the timer, operation mode and rate, complies with ZTE’s requirements.
[Normal result]
The configuration should comply with the actual requirements.
[Troubleshooting]
Configure the error data again. For details, please refer to ZXG10-BSS (V2) Base Station Subsystem
Operation Manual.
194
4.7.3 Performing Secondary Backup on Backup Configuration Data from the

Server to Other Storage Media
[Maintenance tool]
Back up all configuration data set in the server within each week to other storage media with a ftp
backup tool such as “cuteftp”.
[Test procedure]
1. Run the “cuteftp” application in the client or PC.
2. Input the IP address of the sever on the applications interface to log in to this server.
3. Find all configuration backup files from the server and then transfer them to the client or PC in the ftp
mode.
[Normal result]
The data can be smoothly dumped.
[Troubleshooting]
If the ftp operation fails, you may fail to log in to the server or the cached directory authority is read-
only.
If you fail to log in to the server, please check whether the network quality is sound and whether the IP
address is correct. If the problem is with the authority, please modify it.
195
4.7.4 Deleting All Backup Data from the Server

[Maintenance tool]
Clear them manually via the graphic interface of the server or in the character command line mode.
[Test procedure]
1. Enter the directory where the backup files are located.
2. Run a “rm –fr file name/folder name” command to delete backup data.
For more information, please refer to the online documentation (by running the “man” command).
[Normal result]
The backup data to be deleted are cleared and some space is saved.
[Troubleshooting]
If no file is deleted, please check whether the authorities set for the files such as the subject user and
host do not allow this operation.
[Precautions]
This maintenance operation can be executed only after secondary backup of all configuration data in the
server to other storage media.
196
4.7.5 Backing up Several Major Foreground Files
[Maintenance tool]
Use the “omcftp” backup tool to back up the “zxg10.cfg”, “conf”, “dat” and “tcpip.cfg” files.
[Test procedure]
Find the directory for saving the above files to start backup.
[Normal result]
The “zxg10.cfg”, “conf”, “dat” and “tcpip.cfg” files are backed up.
[Troubleshooting]
The “zxg10.cfg”, “conf”, “dat” and “tcpip.cfg” files are not backed up.
4.7.6 Checking Running Status of the Power Equipment
[Maintenance tool]
Observe the panel indicators of the power equipment.
[Test procedure]
Observe the indicators on the power equipment and check whether there is any alarm.
[Normal result]
No alarm is detected.
197
[Troubleshooting]
Please refer to the user manual of the power equipment for troubleshooting.
4.7.7 Checking Running Status of the Transmission Equipment

[Maintenance tool] Check it via the transmission NMS.
[Test procedure] Please refer to manuals related to the transmission NMS.
[Normal result] No alarm is detected.
[Troubleshooting] Please refer to manuals related to the transmission NMS for troubleshooting.
4.7.8 Checking Running Status of the Battery

[Test procedure] Check whether there is any liquid leakage from the batteries and whether the
connection contact is reliable.
[Normal result] No liquid leakage is detected and the connection is normal.
[Troubleshooting] Please refer to the battery usage instruction.
198
Appendix Summary List of BSC Maintenance Items

Please refer to
Checking power voltage
Section 1.1.
Please refer to
Checking equipment room temperature
Environment monitoring Section 1.2.
maintenance check Please refer to
Checking equipment room humidity
Section 1.3.
Checking whether the front and back doors of Please refer to
the rack have been closed Section 1.4.
Main equipment running Please refer to
Checking network management channel
status maintenance check Section 1.5.
Please refer to
Observing current alarm of BSC via the Section Error:
operation & maintenance background Reference
source not found.
Observing current notice of BSC via the Please refer to
199

Observing past 24-hour history alarms of BSC Please refer to
via the operation & maintenance background Section 1.8.
Creating BSC’s daily performance report via Please refer to
the operation & maintenance background Section 1.9.
Please refer to
Checking board running status
Section 1.10.
Checking running status of the background Please refer to
Server maintenance service process Section 1.11.
check Please refer to
Checking server performance
Section 1.12.
Checking whether the database running is Please refer to
Database maintenance normal Section 1.13.
check Checking whether the table space and index Please refer to
space of the database are normal Section 1.14.
Interface running status Please refer to
Checking SS7 link of the central module
maintenance check Section 1.15.
Checking LapD link running status of each Please refer to
module Section 1.16.
200

Checking frame relay status of the Gb Please refer to
interface Section 1.17.
Please refer to
Other maintenance items Duty record
Section 1.18.
Environment monitoring Please refer to
Equipment cleanness
maintenance check Section 2.1.
Please refer to
Viewing busy-hour MP load
Section 2.2.
Please refer to
Communication between MP and each PP unit
Section 2.3 .

Backing up ZDB of all foreground modules
status maintenance check Section 2.4 .
Please refer to
Analyzing history alarms of the past week
Section 2.5 .
Analyzing daily performance reports of the past Please refer to
week Section 2.6.
Please refer to
Database maintenance Backing up configuration data
Section 2.7.
201

Please refer to
Querying and deleting alarm and performance
check Section 2.8 and
data
2.9 .
Please refer to
Antivirus of client computer
Section 2.10 .
Other maintenance items
Please refer to
Checking tool instruments and documentation
Section 2.11 .
Please refer to
Antivirus of client computer
Section 2.10 .
Other maintenance items
Please refer to
Checking tool instruments and documentation
Section 2.11 .
Main equipment running Performing statistics and analysis on all history Please refer to
status maintenance check alarms in the past month Section 3.1 .
Performing statistics and analysis on all daily Please refer to
performance reports in the past month Section 3.2 .
202

Please refer to
Service dialing test
Section 3.3 .
Fetch and print foreground INT13 or Please refer to
ERROR.LOG Section 3.4 .
Please refer to
Backing up alarm data
Section 3.5 .
Please refer to
Backing up and deleting old logs
OMC maintenance check Section 3.6 .
Performing secondary backup on backup data
Please refer to
of this month from the server to other storage
Section 3.7 .
media
Other maintenance items Checking whether the alarm box is running Please refer to
normally Section 3.8 .
Checking spare parts Please refer to
Section 3.9 .
203

Please refer to
Scanning viruses for the client computer
Section 3.10 .
Please refer to
Active/standby board changeover
Section 4.1 .
Active/standby board reset
status maintenance check Section 4.2 .
Please refer to
Network quality test
Section 4.3 .
Please refer to
Checking cable connection
Main equipment running Section 4.4 .
status maintenance check Please refer to
Grounding check
Section 4.5 .
NMC maintenance check Checking system clock of the MP, sever and Please refer to
client Section 4.6 .
204

Please refer to
Checking software version and data
Section 4.7.1
configuration
and 4.7.2 .
Backing up configuration data to other storage Please refer to
media Section 4.7.3 .
Please refer to
Deleting all backup data from the server
Section 4.7.4 .
Please refer to
Backing up several major foreground files
Section 4.7.5 .
Please refer to
Checking power equipment running status
Section 4.7.5 .
Check of corollary Checking transmission equipment running Please refer to
equipment running status status Section 4.7.7 .
Please refer to
Checking battery running status
Section 4.7.8 .
205

05-ZXG10-BSC Daily Maintenance Instruction Manual

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

05-ZXG10-BSC Daily Maintenance Instruction Manual

Încărcat de

Drepturi de autor:

Formate disponibile

ZXG10-BSC Daily Maintenance

1.1 CHECKING POWER VOLTAGE......................................................................................... 4

CHAPTER 2 WEEKLY ROUTINE MAINTENANCE.................................................. 125

2.1 EQUIPMENT CLEANNESS............................................................................................. 126

CHAPTER 3 MONTHLY ROUTINE MAINTENANCE.............................................. 171

CHAPTER 4 HALF-YEARLY ROUTINE MAINTENANCE....................................... 193

4.1 ACTIVE/STANDBY BOARD RESET.............................................................................. 194

Appendix Summary List of BSC Maintenance Items......................................................... 217

Chapter 1 BSC Daily Routine Maintenance

Item Classification Check Item Remarks

Item Classification Check Item Remarks

Item Classification Check Item Remarks

1.1 Checking Power Voltage

1.2 Checking Equipment Room Temperature

[Maintenance tool] None.

1.3 Checking Equipment Humidity

[Maintenance tool] None.

[Maintenance tool] None.

1.5 Checking Network Management Channel

1.5.1 Checking Link Setup between the Server and MP

1 L 209846 178219738 1536 849 36454044 316 173

1 R 417401 5347616 0 12 6215712 32 14

2 L 417401 5347168 0 12 6215280 0 14

2 R 417401 56515404 0 135 9872126 0 23

3 L 417401 55285002 0 132 11305780 0 27

3 R 417401 5347104 0 12 6215280 0 14

4 L 170026 23812584 458 140 4900862 32 28

4 R 417401 5347296 0 12 6215280 32 14

5 L 123 7032786 64 185 1549705 32 40

5 R 417401 5347360 0 12 6215280 32 14

1.5.2 Checking Link Setup between the Server and Client

1.10 Checking Board Running Status

1.10.2Checking Running Status of the SMEM Board

Category Board Location Name Description Meaning Work Mode

Category Board Location Name Description Meaning Work Mode

1.10.3 Checking Running Status of the COMM (MPPP/MPMP) Board

Category Board Location Name Description Meaning Work Mode

Category Board Location Name Description Meaning Work Mode

Category Board Location Name Description Meaning Work Mode

1.10.4Checking Running Status of the COMM (MTP2) Board

Category Board Location Name Description Meaning Work Mode

Category Board Location Name Description Meaning Work Mode

layer board Flashing slowly: The board

1.10.5Checking Running Status of the ECOM (MTP2) Board

Category Board Location Name Description Meaning Work Mode

Category Board Location Name Description Meaning Work Mode

Category Board Location Name Description Meaning Work Mode

1.10.6Checking Running Status of the COMM (LAPD) Board

Category Board Location Name Description Meaning Work Mode

Category Board Location Name Description Meaning Work Mode

Control COMM constantly off: Abnormal

layer board Flashing slowly: The

Category Board Location Name Description Meaning Work Mode

Category Board Location Name Description Meaning Work Mode

1.10.8Checking Running Status of the PEPD (MON) Board

Category Board Location Name Description Meaning Work Mode

Category Board Location Name Description Meaning Work Mode

1.10.9Checking Running Status of the PCOM Board

Category Board Location Name Description Meaning Work Mode

Category Board Location Name Description Meaning Work Mode

1.10.10Checking Running Status of the BOSN Board

Category Board Location Name Description Meaning Work Mode

Category Board Location Name Description Meaning Work Mode

1.10.11Checking Running Status of the DSNI/COMI Board