ZTE-LTE Troubleshooting Guide

ZXSDR OMMB
Troubleshooting Guide
Version: V12.13.30
ZTE CORPORATION
No. 55, Hi-tech Road South, ShenZhen, P.R.China
Postcode: 518057
Tel: +86-755-26771900
Fax: +86-755-26770801
URL: http://ensupport.zte.com.cn
E-mail: support@zte.com.cn
LEGAL INFORMATION
Copyright © 2013 ZTE CORPORATION.
The contents of this document are protected by copyright laws and international treaties. Any reproduction or
distribution of this document or any portion of this document, in any form by any means, without the prior written
consent of ZTE CORPORATION is prohibited. Additionally, the contents of this document are protected by
contractual confidentiality obligations.
All company, brand and product names are trade or service marks, or registered trade or service marks, of ZTE
CORPORATION or of their respective owners.
This document is provided “as is”, and all express, implied, or statutory warranties, representations or conditions
are disclaimed, including without limitation any implied warranty of merchantability, fitness for a particular purpose,
title or non-infringement. ZTE CORPORATION and its licensors shall not be liable for damages resulting from the
use of or reliance on the information contained herein.
ZTE CORPORATION or its licensors may have current or pending intellectual property rights or applications
covering the subject matter of this document. Except as expressly provided in any written license between ZTE
CORPORATION and its licensee, the user of this document shall not acquire any license to the subject matter
herein.
ZTE CORPORATION reserves the right to upgrade or make technical change to this product without further notice.
Users may visit ZTE technical support website http://ensupport.zte.com.cn to inquire related information.
The ultimate right to interpret this product resides in ZTE CORPORATION.
Revision History
Revision No. Revision Date Revision Reason
R1.0 2013-08-30 First Edition
Serial Number: SJ-20130704144811-009
Publishing Date: 2013-08-30 (R1.0)
SJ-20130704144811-009|2013-08-30 (R1.0) ZTE Proprietary and Confidential

Contents
About This Manual ......................................................................................... I
Chapter 1 Overview .................................................................................... 1-1
1.1 Troubleshooting Flow ......................................................................................... 1-1
1.2 Common Maintenance Methods .......................................................................... 1-2
Chapter 2 OMC Software Faults................................................................ 2-1

2.1 Fault Causes ..................................................................................................... 2-1
2.2 Installation and Upgrade Faults ........................................................................... 2-3
2.2.1 Database Connection Fails During Installation ........................................... 2-3
2.2.2 OMM Pre-installation Failure ..................................................................... 2-3
2.2.3 Configuration Fails During Installation........................................................ 2-4
2.2.4 Configuration Center Fails to Obtain the Configured IP Addresses .............. 2-4
2.3 Communication Faults ........................................................................................ 2-5
2.3.1 Disconnected Link Between an NE and OMC............................................. 2-5
2.3.2 Server Keeps on Printing "CODE = 10002" Error Messages........................ 2-6
2.3.3 Topology Tree Link Status Is Different From Actual Link Status ................... 2-6
2.3.4 Database Probe Prompts the Attempt to Set Up a TCP Link ....................... 2-7
2.3.5 Link Broken Alarm Caused by IP Address Conflict...................................... 2-7
2.3.6 System Returns Error Code 46.................................................................. 2-7
2.3.7 Link Broken but No Print information Available on the Server ...................... 2-8
2.3.8 Link Is Broken Between OMMB and BTS and OMMB Server Fails to FTP
or Telnet to BTS ...................................................................................... 2-8
2.4 Performance Management Faults........................................................................ 2-9
2.4.1 Failure to Query Performance Data in the EMS .......................................... 2-9
2.5 Alarm Management Faults .................................................................................2-11
2.5.1 NE Alarms Available on OMMB But Unavailable on EMS...........................2-11
2.5.2 Link Abnormal But No Alarm Available on OMMB or EMS..........................2-11
2.5.3 Failure to Query History Alarms on an OMMB Client................................. 2-12
2.6 Dynamic Management Faults............................................................................ 2-12
2.6.1 Dynamic Command Operation Failure ..................................................... 2-12
2.6.2 Resource Status Queried Through Dynamic Management Is Inconsistent
with the Actual Resource Status............................................................. 2-14
2.6.3 Boards Not In Position Are Reset Successfully......................................... 2-15
2.7 Software Version Faults .................................................................................... 2-15
2.7.1 Fails to Add a Specifications Packet ........................................................ 2-15

2.7.2 Specifications Packet Download Failure/Activation Failure/Pre-Activation
Failure.................................................................................................. 2-16
2.7.3 Specifications Packet Download Requires Addition of a Cell ..................... 2-18
2.7.4 Fails to Find the Specifications Packet to be Deactivated or Deleted.......... 2-18
2.7.5 Pre-Activation Fails ................................................................................ 2-18
2.8 Configuration Management Faults ..................................................................... 2-19
2.8.1 Failure to Upload OMMB Version to the EMS ........................................... 2-19
2.8.2 Configuration Data Synchronization Failure.............................................. 2-19
2.8.3 Snapshot Area Node Not Generated After Successful Synchronization...... 2-20
2.9 Global Faults ................................................................................................... 2-20
2.9.1 DST Configuration Error in the OMC........................................................ 2-20
2.9.2 The OMC Server Console Prompts FTP Boot Failure and File Open
Failure.................................................................................................. 2-22
2.9.3 An EMS Client Failed to Start the OMMB NE Agent and Upload Version
Files..................................................................................................... 2-22
Chapter 3 OS Faults ................................................................................... 3-1

3.1 Solaris System Faults ......................................................................................... 3-1
3.1.1 Abnormal Multi-Client Login After Abnormal Power-Off of the SUN
Server .................................................................................................... 3-1
3.1.2 Incorrect NIC Device Name Causes Abnormal SUN Server Network ........... 3-1
3.1.3 No GUI Available for Applications on SUN Server....................................... 3-2
3.2 Liunx System Faults ........................................................................................... 3-3
3.2.1 VNC Fails to Display the GUI .................................................................... 3-3
3.2.2 Incorrect Character Set After Modification of the i18n File ........................... 3-3
3.2.3 Cannot Open Linux Service Menu ............................................................. 3-4
3.2.4 Hosts File Changed After IP Address Modification and Server Restart ......... 3-4
Chapter 4 Database Faults ........................................................................ 4-1

4.1 Failure in Creating Oracle Listening ..................................................................... 4-1
4.2 OMC Fails to Start.............................................................................................. 4-1
4.3 Error Occurs in Testing the Local Net Service Name............................................. 4-2
4.4 Database Fails to be Connected.......................................................................... 4-3
Glossary .......................................................................................................... I
II

About This Manual
Purpose
This manual describes the way of thinking in troubleshooting of the ZXSDR OMMB OMC
faults and presents typical case analysis.
Intended Audience
This manual is intended for maintenance engineers.
Prerequisite Skills and Knowledge

The following skills and knowledge are the prerequisite in using the manual:
l Radio communication basics and related communications knowledge
l Basic structure and service flows of the BSs
l Radio product networking
l OMMB operations and data configuration rules
l Network structure of the transmission equipment
l Performance parameters of the wireless system
l Efficient use of the test MS and the signaling analyzer helps in fast fault location.
What Is in This Manual

This manual contains the following chapters:
Chapter Summary
1, Overview Describes the ZXSDR OMMB troubleshooting flow and common

maintenance methods.
2, OMC Software Faults Describes the fault symptom, fault cause, and solution of the
ZXSDR OMMB OMC software faults.
3, OS Faults Describes the fault symptom, fault cause, and solution of the
ZXSDR OMMB OS faults.
4, Database Faults Describes the fault symptom, fault cause, and solution of the
ZXSDR OMMB database faults.
Related Documentation
The following documents are related to this manual:
l ZXSDR OMMB System Description
l ZXSDR OMMB Routine Maintenance Guide
Conventions
This manual uses the following typographical conventions:

Typeface Meaning
Italics Variables in commands. It may also refer to other related manuals and
documents.
Bold Menus, menu options, function names, input fields, option button names,
check boxes, drop-down lists, dialog box names, window names, parameters,
and commands.
Constant width Text that you type, program codes, filenames, directory names, and function
names.
[] Optional parameters.
{} Mandatory parameters.
| Separates individual parameters in a series of parameters.
Danger: indicates an imminently hazardous situation. Failure to comply can

result in death or serious injury, equipment damage, or site breakdown.
Warning: indicates a potentially hazardous situation. Failure to comply can

result in serious injury, equipment damage, or interruption of major services.
Caution: indicates a potentially hazardous situation. Failure to comply

can result in moderate injury, equipment damage, or interruption of minor
services.
Note: provides additional information about a certain topic.
II

Chapter 1
Overview
The ZXSDR OMMB faults are categorized into the following types: Operation &
Maintenance Center (OMC) software faults, (AIX, Solaris, Linux, and Windows) OS faults,
and (Oracle) database faults.
Table of Contents
Troubleshooting Flow .................................................................................................1-1
Common Maintenance Methods .................................................................................1-2
1.1 Troubleshooting Flow

For the troubleshooting flow, see Figure 1-1.
Figure 1-1 Troubleshooting Flow
l Collect information
You can collect fault information in the following four ways:

à Complaints from users or the customer center
à Analysis on traffic statistics indexes

à Alarms displayed on the alarm system
1-1

ZXSDR OMMB Troubleshooting Guide
à Abnormalities that are found in routine maintenance or health check

For a confirmed fault, the troubleshooting personnel should contact the OMMB
troubleshooting contact in time to obtain the required information.
l Analyze a fault
After a fault occurs, the troubleshooting personnel need to analyze and locate the fault
in accordance with the fault symptom. In this manual, common faults are categorized
into the following types: OMM faults, hardware faults, system communication faults,
handoff faults, radio load faults, access faults, radio service bearing faults, and global
radio resource faults. According to the fault symptom, the troubleshooting personnel
can locate the fault type, and analyze the fault.
l Locate the fault
Locating a fault is a process of finding a single cause from multiple possible causes.
Through certain methods, the troubleshooting personnel compare the possible fault
causes, eliminate the impossible factors, and finally determine the actual cause of the
fault.
Accurate fault location requires that the troubleshooting personnel have accumulated
experience and knowledge.
l Eliminate the fault
Eliminating a fault is a process of getting rid of a fault by adopting proper measures
or steps, such as inspecting lines, replacing boards, modifying configuration data,
switching over the system, and resetting boards. In eliminating a fault, strictly follow
the methods and steps that are described in the operation manual or maintenance
manual.
l Record the fault
The entire process of troubleshooting needs to be recorded. The troubleshooting
personnel need to record the fault occurrence time, fault occurrence location,
troubleshooting personnel, fault symptom, and troubleshooting method. Good fault
recording habit helps the maintenance personnel to accumulate the troubleshooting
experience, shorten the fault location time, and speed up fault elimination.
l Share the experience
After a fault is eliminated and recorded, the maintenance personnel need to share the
troubleshooting experience in time, so as to improve the overall troubleshooting skills
and efficiency of the related troubleshooting personnel.
1.2 Common Maintenance Methods

Common maintenance methods include alarm and operation log query, performance
analysis, and self-test.
1-2

Chapter 1 Overview
Alarm and Operation Log Query

Alarm and operation log query is the first method that is used by the troubleshooting
personnel in the case of a fault. Users can query alarms and operation logs through the
alarm management window and the operation log query window of the operation and
maintenance subsystem Operation & Maintenance Module (RNC) (OMMB).
Through the alarm management window, users can observe and analyze alarm information
such as current alarms, history alarms, and notifications that are reported by the NEs.
The alarm information helps them to find the abnormalities that occur during the network
operation process, locate faults, isolate the faults, and eliminate the faults.
By querying the operation logs in the user management window, users can trace the
modification of system parameters, locate the terminal and operator that are responsible,
and find the faults that are caused by personal operations.
For the location and usage of the OMC logs, refer to Table 1-1.
Table 1-1 OMC Log Location and Usage
Type Location Usage
Server logs The files similar to server-20090923-0132-1001 They are used to troubleshoot
0.log in the ums-svr/log/ directory all the faults that are related
to the OMC.
Client logs The files similar to client-20090812-1502-4139 They are used to troubleshoot
5.log in the ums-clnt/log/ directory the faults that are related to
the client.
GC logs The files similar to gc-09-05-27-16-06-52.log in They are used to troubleshoot

the ums-svr/log/ directory the faults such as low OMC
operating speed and OMC
Rmon logs All the files in the ums-svr/platform/psl/uep-p crash.
sl-rmon.par/data directory
Stacked All the files that are at the specified time point in the
print ums-svr/log/console-ums directory
Memory All the java_pid*.hsrop files and the files that start
dump with dump in the ums-svr/log directory
FTP logs All the files in the ums-svr/tools/ftpserver/log They are used to troubleshoot
directory the FTP faults.
Startup logs The boot.log, console.log, and They are used to troubleshoot
server-start.log in the ums-svr/log/ the OMC startup failure.
directory.
If an error occurs during the Operation and Maintenance Module for BTS, NodeB and
eNodeB (OMMB) installation, you can start a simple analysis on the OMMB installation
logs.
Installation log directory:
1-3

In the Windows OS, the installation logs are in the C:\Documents and Settings\All
Users\.omc directory.
In the Unix OS or Linux OS, the installation logs are in the /home/User name/.omc
directory. If the root user account is used to install the OMMB, the installation log is in the
/root/.omc directory for the Linux OS and /.omc for the Aix OS.
Log names:
Installation logs: installYYMMDDhhmmss.log, YYMMDDhhmmss is the timestamp.
Configuration center logs: configYYMMDDhhmmss.log
Temporary files that are generated in the installation process: scriptlistYYMMDDhhmm
ss.xml, copyfilelistYYMMDDhhmmss.xml
Send the installation logs, configuration center logs, and the temporary files that are
generated in the installation process to the customer service center.
Performance Analysis
Performance analysis is performed through the performance management window of the
operation and maintenance subsystem. Through the performance management window,
the troubleshooting personnel can implement system performance management and
signaling tracing.
Through the performance management window, users can create various performance
measurement tasks so as to generate various performance reports and learn the
performance indexes of the Radio Network Controller (RNC) system. By analyzing
the information, the troubleshooting personnel can learn load distribution status in the
network, and adjust the network parameters in time to improve the network performance.
Through the signaling tracing window, users can trace signaling. This facilitates signaling
flow query during office deployment debugging and maintenance, helping to find the
problems in signaling cooperation.
Self-Test
When the system or boards are powered on again, self-test is used to judge the faults.
Self-test of a board is usually performed during re-power-on. During the process, the
indicators on the panel flash regularly, based on which users can determine whether the
board is faulty.
Diagnosis Management
The diagnosis result file is in the ums-svr\dtm\subnet[Subnet No.]\nodeb[NE No
.] directory or in the ums-svr\dtm\[Subnet No.]\[NE No.]\ directory. The former
directory is the directory for saving the reported diagnosis task result, and the latter is the
directory for saving one diagnosis result of single-NE diagnosis. The file in the directory is
reported by the NE, and the file name is dtmBoardTest.xml.
For example, for the NE with the subnet number 1 and NE number 1, the directory is
ums-svr\dtm\subnet1\nodeb1\ or ums-svr\dtm\1\1\.
1-4

Chapter 1 Overview
Path for diagnosis and resolution template: \ums\ums-svr\sdrmanager\sdrmanager

-osf\sdrmanager-osf-dtm.par provides different versions for different modes. The
files are converted from the NE and OMC interface diagnosis templates. Based on the
files, the OMC resolves the diagnosis result that is reported from the NE side, and then
presents the final resolution result to the client.
NE and OMC interface diagnosis documents are maintained and released by the NE. The
NE converts the pre-diagnosis OMC interface template (in the Excel form) in the document
into the XML file that is required by the OMC.
Path for diagnosis client jar packet: \ums\ums-clnt\sdrmanager\sdrmanager-
wsf\sdrmanager-wsf-dtm.par\ sdrmanager-wsf-dtm.jar; server jar packet:
\ums\ums-svr\sdrmanager\sdrmanager-osf\sdrmanager-osf-dtm.par\
sdrmanager-osf-dtm.jar.
Three types of diagnosis are supported:
l Single diagnosis
Select one item for diagnosis.
l Combined diagnosis
Select two or more items for diagnosis.

Input of the combined diagnosis parameters. A diagnosis item with parameters cannot
be combined with other diagnosis items. The diagnosis item with parameters can only
be diagnosed alone.
l Batch diagnosis
Batch diagnosis tasks are supported, and the command is sent as a single diagnosis
command.
In a batch diagnosis task, the number of NEs and functions that are contained in the
task must be controlled. Otherwise, the diagnosis takes a long time.
For the diagnosis items and the corresponding analysis, refer to Table 1-2.
Table 1-2 Diagnosis Item and Analysis
Diagnosis Result Analysis
Chinese characters The diagnosis module resolves the diagnosis result based on the NE and
are displayed. OMC interface templates. If the diagnosis result is displayed in Chinese in
the English environment, there are two possible causes: 1) The OMC uses
an incorrect interface document, and the OMC of the English version uses a
diagnosis template of the Chinese version. 2) The diagnosis template of the
English version that is provided by the BTS contains Chinese characters.
If the fault occurs, send the snapshot of the window to the out-of-office
troubleshooting contact of the OMMB.
1-5

Diagnosis Result Analysis
No unit is displayed. The unit of a diagnosis result of an element is defined in the NE and OMC
interface format description, in the form of % and the specific unit. In
resolution on the OMC, the specific value is used to replace %. If the unit of
a diagnosis result of an element is incorrect, request the NE to modify the
NE and OMC interface documents.
"Exception occurred The diagnosis result file reported by the NE fails to comply with the content
while calling local format defined in the NE and OMC interface documents, or the diagnosis
application service!" is result value is different from the values defined in the NE and OMC interface
displayed. documents, the OMC fails to resolve the result based on the templates. In
this case, the NE and OMC are request to locate the fault together.
A 6-digit number is The OMC resolves the result based on the item ID in the diagnosis and
displayed. resolution template. If the item ID that is reported by the NE is not contained
in the diagnosis and resolution template, the OMC fails to resolve the item
ID. Then, the item ID is displayed. In this case, request the NE to modify
the NE and OMC interface template.
Error Result or For enumerated types and other types that are with abnormal enumerated
No Match Value is values, the OMC resolves the diagnosis result based on the enumerated
displayed. values. If the diagnosis result value and the enumerated values do not
match, the OMC fails to resolve the diagnosis result value, then the fault
occurs. In this case, request the NE to modify the enumerated values in the
NE and OMC interface diagnosis template.
An error code and Check whether the links between the OMM server and BTSs are normal. In
FTP-related errors are the \ums\ums-svr\sdrmanager\sdrmanager-osf\sdrmanager-o
displayed. sf-dtm.par\mediator-sdrmap-dtm-action-snmp-conf.xml file,
check the FTP property settings dtmSingleTestFtpUserName= common
and dtmSingleTestFtpPassword=SdrPub2012.
An error code is Contact the ZTE technical support.

displayed and timeout
is prompted.
An error code or an
error message is
displayed.
Other messages or
uncertain results are
displayed.
1-6

Chapter 2
OMC Software Faults
OMC software faults can be categorized into the following types:
l Installation and upgrade faults: refers to the faults that occur during the installation
and upgrade of the OMC, and during the startup of the OMC server and client.
l Communication faults: mainly refers to the communication failures between the OMC
server and clients and between the NEs and server.
l Performance management faults: refers to performance data setting, query,
measurement, and report management faults, and the faults related to signaling
tracing.
l Alarm management faults: refers to the faults related to alarm setting, alarm query,
and alarm box management.
l Dynamic management faults: refers to the faults related to the running of dynamic
management commands and the query of resources.
l Software version faults: refers to the abnormalities and failures that occur during the
download, activation, running, and deletion of software versions.
l Configuration management faults: refers to data configuration faults, data
synchronization faults, time synchronization faults, and data configuration tool faults.
l Global faults: refers to the global functional faults related to all modules of the OMMB,
for example, log faults and rights management faults.
l
Table of Contents
Fault Causes ..............................................................................................................2-1
Installation and Upgrade Faults ..................................................................................2-3
Communication Faults................................................................................................2-5
Performance Management Faults...............................................................................2-9
Alarm Management Faults .......................................................................................2-11
Dynamic Management Faults ...................................................................................2-12
Software Version Faults............................................................................................2-15
Configuration Management Faults............................................................................2-19
Global Faults ............................................................................................................2-20
2.1 Fault Causes

OMC alarms are related to OMC installation, upgrade, and operation, as well as data
backup and recovery.
For the common device management faults, refer to Table 2-1.
2-1

Table 2-1 Common Device Management Faults
Category Common Causes
Installation and upgrade l Incorrect Oracle database instance information leads to a database
faults connection failure.
l Failure to execute the database script leads to an installation or
upgrade failure.
l Improper network configurations (such as IP address) lead to a
startup failure of the OMC.
Communication faults l The server IP address that is set on the client is incorrect, causing
the failure of the client in connecting to the server.
l On an OMC, the operation and maintenance IP address of an NE
is incorrect, causing the communication failure between the server
and the NE.
l The hardware faults of the NIC and network cable cause the
communication failure.
Performance l The character set is incorrectly set for the databases. Therefore,
management faults during the upgrade of the database scripts, a performance script
error occurs.
l The database upgrade causes the failure in querying counters.
l The abnormal physical connection or abnormal NE signaling tracing
module causes the failure in signaling tracing connection.
l The switch is set incorrectly, causing that no signaling tracing data
is reported.
Alarm management faults l The IP address of the alarm box is incorrect or the OMC parameters
are incorrect, causing the failure in connecting the alarm box.
l The alarm filtering rule is incorrect; therefore, certain alarms are
not available in the OMC.
Software version faults Insufficient FTP resources lead to a software version download failure.
Configuration l Incorrect data configuration or data verification failure causes the

management faults data synchronization failure.
l Failure to start the NTP server or improper configuration of the NTP
server causes the NTP time synchronization failure.
l When the fast configuration tool is used, incorrect board
configuration causes errors during data generation.
l When the fast configuration tool is used to generate the data scripts
for service cells, the managed NEs are not configured in the global
radio resources, causing abnormal data.
Global faults l Improper configuration of rights leads to unavailability of some

functions.
l Excessive IMS messages lead to failures to implement some
functions.
l Some interfaces respond slowly, or even do not respond.
2-2

Chapter 2 OMC Software Faults
2.2 Installation and Upgrade Faults

2.2.1 Database Connection Fails During Installation
Fault Symptom
During the installation, in the database configuration window, set the database
configuration data and click Next. The database connection failure message is displayed.
Fault Cause
l The monitoring service is not started.
l The database service is not started.
l The inputted user name or password is incorrect.
Solution
1. Log in as the oracle user, and run the following commands to check the listening status.
$ lsnrctl stat
oracle@linux17653:~/Desktop> lsnrctl stat
If the listening status is abnormal, restart listening.
$ lsnrctl stop
$ lsnrctl start
2. Check whether the database instance is normal.
oracle@linux17656:~> export ORACLE_SID=ommb //Input the actual instance name.
oracle@linux17656:~> sqlplus system/oracle //Input the actual password.
2.2.2 OMM Pre-installation Failure

Fault Symptom
During the pre-installation process, the pre-installation failure message is prompted.
Fault Cause
During the OMMB initial installation, if the installation directory already exists, the installer
deletes the existing directory and creates the new directory.
Solution
1. Check whether certain files in the installation directory are in use. If they are in use,
stop the processes that use the files or select another installation directory.
2. If you cannot determine the files that are in use, restart the server and start the
installation again.
2-3

2.2.3 Configuration Fails During Installation

Fault Symptom
During the installation, the configuration in the configuration center fails owing to some
incorrect configuration items.
Fault Cause
In the configuration center, some configuration items are incorrect, causing the failure in
saving the configuration data.
Solution
After the installation is completed, open the config-xxx.sh file in the config-xxx.sh
directory to start the configuration center, configure data again and save the configuration.
Note:
If you start the configuration center alone, after the configuration, restart the OMMB to
validate the configuration.
One server can be configured with only one Dynamic Host Configuration Protocol (DHCP)
service. If a server is configured with more one DHCP service, the configuration center
fails to pass the verification. Clear the DHCP check box. To stop the DHCP service of
another OMMB, start the configuration center in the installation directory of the OMMB for
modification.
2.2.4 Configuration Center Fails to Obtain the Configured IP

Addresses
Fault Symptom
Multiple IP addresses are configured on the Aix and Linux servers, and the IP addresses
can be queried through the ifconfig –a command. However, in the IP address
configuration window of the configuration center, only one IP address can be detected
through the tool.
Fault Cause
l The IP addresses that are configured in the Host file are incorrect.
l The cache function of the nscd service is enabled. (This cause is applicable only for
the Linux OS.)
2-4

Solution
1. Log in as the root user, and input the following command in the command terminal to
check the IP addresses that are configured for the server.
# ifconfig –a
2. Open the /etc/hosts file and check the file contents.
l Hostname must not be Localhost.
l 127.0.0.1 must not be in the first row of the file.
l For each IP address that can be queried through the ifconfig command, there
must be a row in the hosts file.
In the case of the Linux OS, in addition to above, check the following:
l Open the /etc/host.conf file and check whether there is a row containing multi
on. If not, add the row. multi on means to allow one host name to have multiple IP
addresses.
l Disable the cache function of the nscd service. Open the /etc/nscd.conf file, and
change enable-cache hosts yes to enable-cache hosts no.
Restart the nscd service to validate the settings.
# rcnscd restart
2.3 Communication Faults

2.3.1 Disconnected Link Between an NE and OMC
Fault Symptom
l In accordance with packet capture, the IP address of the NE and the IP address of
the OMC are not in the same network.
l The server log keeps on printing the "Cannot bind to any local address" message.
Fault Cause
The IP address that is configured in the ums\ums-svr\deploy\deploy-sdrmanager
.properties configuration file in the OMMB installation directory does not exist or the
IP address configuration is incorrect.
Solution
1. In the OMMB installation directory, open the install\lib\bin folder, and then open
the OMMB configuration center.
l In the Windows OS, open the config.bat file.
l In the Linux OS, open the config.sh file.
2. Set a correct communication IP address for the NE.
3. Restart the OMMB server.
2-5

2.3.2 Server Keeps on Printing "CODE = 10002" Error Messages

Fault Symptom
The server window keeps on printing "CODE = 10002" error messages.
Fault Cause
The SNMP link of the NE is occupied, that is, it is not released. In this way, the link between
the OMC and the NE cannot be set up.
Solution
l Telnet to the NE and input the ShowSNMP command. Check whether the two IP
addresses in the print information are the same as the NE communication IP address
of the OMMB. If the IP addresses are different, it indicates that the NE is occupied by
another OMMB. In this case, let the OMMB that occupies the IP addresses release
the management on the NE.
l If the print information shows only one IP address, contact the ZTE technical support.
2.3.3 Topology Tree Link Status Is Different From Actual Link

Status
Fault Symptom
l The topology tree indicates that the link is disconnected, but the NE version can be
queried.
l The topology tree indicates that the link is connected, but the link disconnected
message is returned after NE version query.
Fault Cause
The Java Message Service (JMS) message is lost, or the NE status on the topology tree
cannot be refreshed automatically.
Solution
1. On the Element Management System (EMS) client, select Topology > Refresh Data.
If the fault still exists, perform the next step.
2. Right-click a target NE proxy, and select Configuration Management from the
shortcut menu. The Configuration Management window is displayed, right-click the
top node in the left navigation tree, and select Refresh from the shortcut menu. If the
fault still exists, perform the next step.
3. Save other configuration data on the EMS client, and restart the EMS client.
2-6

2.3.4 Database Probe Prompts the Attempt to Set Up a TCP Link

Fault Symptom
In the database probe window, query the NE database. The query result prompts the
attempt to set up a Transfer Control Protocol (TCP) link.
Fault Cause
l The subnet number and NE ID to be queried are input improperly.
l There is a problem with the TCP link.
Solution
1. Check whether the subnet number and NE ID that are specified in the database probe
window are consistent with those in the configuration window.
2. If there is a problem with the TCP link, contact the ZTE technical support.
2.3.5 Link Broken Alarm Caused by IP Address Conflict

Fault Symptom
Link broken alarms are reported every one to two minutes, and the system gives the IP
address conflict notification, in which the Medium Access Control (MAC) addresses of the
conflicting parties are prompted.
Fault Cause
The IP addresses of two OMCs are the same. This result in loss of messages that are
reported by NEs.
Solution
1. Modify the IP address of an OMC server.
2. Modify the NE communication IP address in the OMMB configuration center window.
2.3.6 System Returns Error Code 46

Fault Symptom
l After the configuration synchronization or another operation is performed, the NE
usually returns error code 46. After resetting the NE, pinging the IP address succeeds.
l The queried version is different from the VMP version in telnet.
2-7

Fault Cause
The IP addresses of two NEs are the same. In this case, errors occur when the OMC
sends imple Network Management Protocol (SNMP) messages.
Solution
In the configuration management window of the OMMB client, modify the IP address of
either NE.
2.3.7 Link Broken but No Print information Available on the Server

Fault Symptom
The link is broken but the "create v3 fail:" print information of the NE is not available in the
server window.
Fault Cause
The link of the NE is in the "Swapping", "Configuring" or "Manual Link Broken" state.
Solution
1. In the configuration window, query the status of the NE.
If the operation and maintenance status is "Configuring", change it to "Normal". If the
cutover status is "Swapping", change it to "Normal".
2. Start the dynamic management window, and perform the "Query Manual Link State "
operation. If the link is in the "Manual Link Broken" state, perform the "Manual Link
Restore" operation.
2.3.8 Link Is Broken Between OMMB and BTS and OMMB Server
Fails to FTP or Telnet to BTS
Fault Symptom
The OMMB client can ping a BTS normally, but it cannot FTP or Telnet to the BTS. The
link between the OMMB server and the BTS is broken.
Fault Cause
The OMMB server uses a new IP address, and the subnet mask of the IP address of
the transmission managed object (Operation & Maintenance Center for Node B (OMCB))
whose data is configured on the BTS is improper. The new IP address of the OMMB server
is not in the same network segment as the transmission OMCB. For example, if the subnet
mask is 255.255.255.255, an error occurs only if the OMMB server uses a new IP address.
2-8

Solution
1. Use the previous IP address for the OMMB server, and ensure that the IP address is
not used by another server. Then, restart the OMMB server.
2. Modify the subnet mask of the IP address of the transmission OMCB that is configured
on the BTS so that the new IP address of the OMMB server is in the network segment.
Perform the configuration data modification and incremental synchronization
operations.
3. Use the new IP address for the OMMB server, and then restart the OMMB server.
Check whether the fault is cleared. If the fault persists, contact ZTE technical support.
2.4 Performance Management Faults

2.4.1 Failure to Query Performance Data in the EMS
Fault Symptom
Performance data fails be queried in the EMS.
Fault Cause
l Check whether a task has been configured.
l Check the commissioning status of the NE.
l Check whether the OMMB has received data from BTSs.
l Check whether data processing of the OMMB fails.
l Check whether the EMS has received data from the OMMB.
Solution
1. Check whether a task has been configured.
l For a basic measurement type, no task need to be set. Proceed to the next step.
l For a common measurement type, check whether a task has been set in the EMS,
and check whether the current time is within the period between the start time and
end time of the task.
l If a task has been set on the EMS, check whether the NE has received the task.
Telnet to the CC board to check the task:
a. In the configuration, view the external IP address of the NE.
b. Telnet to the external IP address of the NE, that is, log in to the CC board.
c. Enter ./ushell, and then enter the user name and password.
d. Enter ps to view the process number of MGR.
e. Enter the process number of pad MGR .
f. Enter dbtr 1040 to view the non-basic measurement types for which data
need to be collected.
2-9

If no task can be queried in the NE, then the synchronization time point of the task
in the OMMB is as follows:
à If the time for creating a task is in the first 10 minutes of every 15 minutes,
then the measurement types of the EMS task can be queried on the CC board
after the 10th minute.
à If the time for creating a task is in the last 5 minutes of every 15 minutes, then
the measurement types of the EMS task can be queried on the CC board after
the 10th minute of the next 15 minutes.
à If a link broken error occurs during the task synchronization process, the task
synchronization time may be delayed for 15 minutes.
If you fail to query the task on the NE after waiting a period of time, return to the
ums\ums-svr\log directory to view the log of the period of time.
In the case of fault locating through the OMC, query the following contents in
the log: The following print information indicates the measurement types that are
processed by the OMMB and are to be delivered to the NE, and indicates whether
they have been delivered successfully.
2011-11-21 16:25:00,015 INFO
[com.zte.ums.sdrommb.pm.emf.task.PmEmfTaskDistrProc] There
is(are) 2 task(s) in the NeedStartNePoMap
2011-11-21 16:25:00,015 INFO
[com.zte.ums.sdrommb.pm.emf.task.PmEmfTaskDistrProc]
the neMOI is SubNetwork=0,MEID=0, the PO(s) is(are) :
37336,37339,37335,37354,37350,37337
2011-11-21 16:25:00,031 INFO
[com.zte.ums.sdrommb.necomm.snmp.handler.AbstractSnmpActionHandler]
SnmpService handle operation type pmpCreateTask(SubNetwork=0,MEID=0
set sucess
2. Check the commissioning status of the NE.
Through Traceme, check whether the BTS reports data: check OAM PMP of PLAT.
During the first two minutes of every 15 minutes, the BTS prints the reported file
information. If TEST_DEBUG is printed, it indicates that the BTS is in debugging
status and it does not report data.
3. Check whether the OMMB has received data from BTSs.
In the log file, search PmDataCollectTimerTask]receive file. If the print
information fails to be found, or the print information about the related subnet or NE
fails to be found, it indicates that the BTS did not report data to the specified directory.
Check the print information of Traceme. If the BTS has successfully report files, FTP
Success is printed.
4. Check whether data processing of the OMMB fails.
In the related log files, search .pm, and check whether there is WARN or ERROR.
2-10

If the following print information exists but the corresponding file is not available in
the compressed files, the possible cause is that the NE did not perform any service
operation and the BTS did not write the data file.
5. Check whether the EMS has received data from the OMMB.
Check the bak directories of the measurement object types in the EMS file directory.
For example, in the D:\NetNumen\ommb-b2-1108\ums\ums-svr\tmp\ftp\pm
\SDR-II\eNodeB(LTETDD)\bak directory, check whether the file in the required
period of time exists, such as eNodeB(LTETDD)_201111241432+080024A20111
124.1415+0800-20111124.1430+0800_0_1_781_1_0.csv.
In the file name, eNodeB(LTETDD) indicates the measurement object type, 080024
A20111124.1415+0800-20111124.1430 indicates the start time and end time of
the data in the file.
If the file exists, it indicates that the EMS has obtained the file. If the file still cannot be
queried on the EMS, contact the ZTE technical support.
2.5 Alarm Management Faults

2.5.1 NE Alarms Available on OMMB But Unavailable on EMS
Fault Symptom
The alarms of an NE are displayed on the OMMB normally but the alarms are not displayed
on the EMS.
Fault Cause
The maintenance status of the NE has been set to Testing or PM Testing. Therefore, the
OMMB does not report alarms to the EMS.
Solution
1. Open the configuration management window, double-click the NE, and then set
Maintain Status to Normal.
If the NE alarms are still not displayed on the EMS, perform the alarm synchronization
operation on the NE through the EMS.
2. If the fault persists, contact the ZTE technical support.
2.5.2 Link Abnormal But No Alarm Available on OMMB or EMS

Fault Symptom
The link is abnormal. There are faults on the NE, but no alarm is available on the OMMB
or EMS.
2-11

Fault Cause
The NE is in the Testing status, hence it does not report alarms to the OMC.
Solution
1. In configuration management, select the NE, and then select the modification area.
2. Under the MOC tree behind the NE tree, expand Radio Parameter, and double-click
MOC of any mode.
3. In the right pane, a unique record is displayed. Double-click the record, and modify
Product Status to Normal. Save the modification and start configuration data
synchronization.
4. If there is still no alarm on the OMMB or EMS, perform the alarm synchronization
operation on the NE through the OMMB or EMS.
5. If the fault persists, contact the ZTE technical support.
2.5.3 Failure to Query History Alarms on an OMMB Client

Fault Symptom
History alarms fail to be queried on an OMMB client.
Fault Cause
On an OMMB client, only the history alarms that are generated after the client login can
be queried. In addition, only the latest 1000 alarms are saved. (That is, 1000 alarms are
saved for all NEs.) After the client is restarted, all history alarms are cleared.
Solution
No processing is required. You can use the integral alarm function of the EMS.
2.6 Dynamic Management Faults

2.6.1 Dynamic Command Operation Failure
Fault Symptom
Dynamic command operation fails.
Fault Cause
Use the system tool Traceme to view 050—OAM SNMP of PLAT Public. The NE side
prints the error code 20003.
The fault cause is the database operation failure on the NE side. There are two probable
cases for the failure:
2-12

l The resource object that is operated through dynamic management does not exist in
the NE database table.
l The value sent by the dynamic command to the NE is incorrect.
Solution
1. Check whether the resource object that is operated through dynamic management
exists in the NE database table.
a. Telnet to the NE, enter ./ushell, and then enter the user name and password.
b. Input ps to view the MGR process number. View the pad MGR process number.
c. Input dbsn to view the NE table serial number. View the dbtr NE table serial
number.
2. View whether the resource that is operated through dynamic management exists in
the NE table.
The resource object that is operated through dynamic management is the configuration
data that is obtained through the modification area of the configuration management
module. If the resource to be operated does not exist in the NE table, you need to
synchronize configuration data so that the NE data and the OMC data are consistent.
3. If the resource to be operated exists in the NE table, ensure that the values that are
specified in the message that is sent by the OMMB are correct. Use the system tool
Traceme to view 066—OAM DDM of PLAT Public. After the NE receives the message,
it prints the received values, as follows:
208 2012-6-4 15:44:17.0 [INFO] 6145-1-1-1-1-0X10c01
[P_R_DDMManager.c:340][DDM Trace] Manager rcv Qry
Msg!!!,Sender:dwPno[268566529]!
214 2012-6-4 15:44:17.0 [INFO] 6145-1-1-1-1-0X10c01
[P_R_DDMManager.c:1450][DDM Trace]Qry
Data,[QryType]37,[QryRack]1,[QryShelf]1,[QrySlot]1,[QryKey]1,[QryRKey]255.
179 2012-6-4 15:44:17.0 [INFO] 6145-1-1-1-1-0X10c01
[P_R_DDMManager.c:1706][DDM Trace] Qry Resouse from Dbs succ,
[status]0,[MOp]-1.
0 2012-6-4 15:44:17.0 [INFO] 6145-1-1-1-1-0X10c01

[P_R_DDMManager.c:1494][DDM Trace] Qry Succ and Send to
Omc/LMT.dwQryStatus=0,dwManualOp=-1
Check the operation type, rack, shelf, slot, and keyword. If the values are incorrect,
modify the OMMB program.
2-13

2.6.2 Resource Status Queried Through Dynamic Management Is

Inconsistent with the Actual Resource Status
Fault Symptom
The resource status queried through dynamic management is inconsistent with the actual
resource status.
Fault Cause
The resource statuses queried through dynamic management are saved in the NE
database table. If the resource statuses are changed but the statuses are not updated
in the NE database table, such fault occurs.
Solution
1. Check whether the queried resource status is the same as the status that is saved in
the NE database table.
a. Telnet to the NE, enter ./ushell, and then enter the user name and password.
b. Input ps to view the MGR process number. View the pad MGR process number.
c. Input dbsn to view the NE table serial number. View the dbtr NE table serial
number.
2. View the values of the dwStatus and dwManualOp fields in the NE table for the
resources that are queried through dynamic management.
The dwStatus field is the status field. For the meanings of the field values, refer to
Table 2-2.
Table 2-2 Meanings of Each Bit of the Status Value
Status Field (dwStatus) Value Description
Bit0 1/0 Faulty/Normal
Bit1 1/0 Standby/Active
Bit2 1/0 Unavailable/Available
Bit3 1/0 Initial/Normal
Bit4 1/0 In operation/Not in operation
Bit5 1/0 Testing/Normal
Bit6 1/0 Logically faulty/Logically

available
Bit7 1/0 Power saving status/Normal

status
Bit8-Bit31 0 Reserved
2-14

The dwManualOpis field is the status field. For the meanings of the field values, refer
to Table 2-3.
Table 2-3 Meanings of Each Bit of the Manual Operation Field Value
Manual Operation Field Value Description

(dwManualOp)
Bit0 1/0 Block/Unblock
Bit1 1/0 Commissioned/Not

commissioned
Bit2 1/0 Power off/Power on
Bit3 1/0 Allow to write flash/Not allow

to write flash
Bit4-Bit31 0 Reserved
2.6.3 Boards Not In Position Are Reset Successfully

Fault Symptom
In dynamic management, after the operation of resetting boards is performed, the system
prompts that the boards that are not in position are reset successfully.
Fault Cause
Before the boards are reset, the availability and unavailability judgment has been
neglected.
Solution
No processing is required.
To meet certain special requirements, if the NE receives the board reset commands, the
NE regards the operations as successful.
2.7 Software Version Faults

2.7.1 Fails to Add a Specifications Packet
Fault Symptom
When adding a specifications packet, it is prompted that the specifications packet already
exists. However, the specifications packet does not exist.
2-15

Fault Cause
The restriction on adding a specifications packet includes format, type, and version
number. The three factors are controlled as one keyword.
Solution
Find the specifications packet that has the same format, type, and version number as the
one that you want to add. Delete the existing specifications packet and add the required
one.
2.7.2 Specifications Packet Download Failure/Activation

Failure/Pre-Activation Failure
Fault Symptom
The specifications packet fails to be downloaded, the activation fails, or the pre-activation
fails.
Fault Cause
The specifications packets that are saved in the NE have three states: standby, active,
and running. For the restraint relation of the three states, refer to Table 2-4.
Table 2-4 Constraint Relation of Three States of the Specifications Packets
Specifica- Pre- Download Deletion Deactivation Activation for

tions Packet Activation Validation
Status
Standby status Pre-activation Incremental Deletion is Deactivation Activation for

is allowed. download is allowed. is not allowed. validation is
allowed. (Deactivation not allowed.
cannot be (If no activated
performed packet is
on a single available in the
packet.) entire system,
activation for
validation is
not allowed.)
2-16

Specifica- Pre- Download Deletion Deactivation Activation for

tions Packet Activation Validation
Status
Activated Pre-activation Downloading Deletion is not Deactivation Activation for

status is not allowed. is not allowed. allowed. is allowed. validation is
(If you allowed.
perform the
deactivation
operation, all
the activated
specifications
packets are
deactivated.)
Running Pre-activation Incremental Deletion is not Deactivation is Activation for

status is not allowed. download is allowed. not allowed. validation is
allowed. not allowed.
For the conversion relation between the standby, activated, and running states, refer to
Table 2-5.
Table 2-5 Conversion Between State A and State B
Fault Category B: Standby B: Pre-activation B: Running
A: Standby - Pre-activation Pre-activation and

activation are required
for validation.
A: Activated Deactivation - Validation
A: Running After another After another -

specifications packet specifications packet
is upgraded, the is upgraded, the
specifications packet specifications packet
that is in the running that is in the running
state currently enters state currently enters
the standby state. the standby state.
Activate the standby
specifications packet.
Solution
Select the Query Task Management node to create a query task. In the result, the status
of the current specifications packet is displayed.
Strictly follow the constraint relation and conversion relation for operations.
2-17

2.7.3 Specifications Packet Download Requires Addition of a Cell

Fault Symptom
In downloading a specifications packet, a prompt message is displayed, saying that
the format of the specifications packet is different from the cell format of the BTS. It is
required that a cell in that format be added or modified and then the configuration data be
synchronized.
Fault Cause
In downloading specifications packets, the filtration is not based on the cell format of the
BTS; instead, the filtration is based on the format of the BTS.
Solution
1. In the radio parameters of the BTS, add cell data.
2. In the configuration management module, synchronize data.
3. Download the specifications packet.
2.7.4 Fails to Find the Specifications Packet to be Deactivated or

Deleted
Fault Symptom
In the window, the specifications packet to be deactivated or deleted cannot be found.
Fault Cause
A special task is running, and only the stored specifications packets are displayed.
Solution
Perform the query operation. In the query result table, right-click and select Create
Deactivate Task or Create Delete Package Task.
2.7.5 Pre-Activation Fails

Fault Symptom
The specifications packet that is saved on the NE can be queried, but pre-activation of the
packet fails.
Fault Cause
The file download is incomplete.
2-18

Solution
After the specifications packet is downloaded completely, pre-activate it.
2.8 Configuration Management Faults

2.8.1 Failure to Upload OMMB Version to the EMS
Fault Symptom
The OMMB version fails to be uploaded to the EMS.
Fault Cause
l The NE agent is not started normally.
l The command terminal cannot switch to the NE agent normally.
l On the OMMB server, the client file ums\ums-svr\ems-client\ommb-ems-clie
nt.zip is lost.
Solution
1. Check whether the NE agent is started normally.
2. Check whether the command terminal can switch to the NE agent.
3. Check whether the client file ums\ums-svr\ems-client\ ommb-ems-client.z
ip exists on the OMM server.
4. Delete the ums-client/rundata directory, restart the client, and reload the OMMB
version.
2.8.2 Configuration Data Synchronization Failure

Fault Symptom
Synchronization fails.
Fault Cause
NE processing fails: The configuration parameters are incorrect.
The bases of the data are inconsistent.

l No entire table is available for the (new, imported, or recovered) NEs, and only the
incremental data is provided.
l The serial numbers are not updated after the synchronization is successful.
l The serial numbers are not updated after the configuration data is activated and
validated.
l The data has been modified by the LMT.
2-19

Solution
NE processing fails:
At the lower left corner of the synchronization window, click the Parameters check button
to check whether there are parameter configuration errors.
If no error is found in parameter check but the synchronization still fails, send the
synchronization failure message snapshot, server logs, and the exported configuration
data of the NE to the ZTE technical support of ZTE.
The bases of the data are inconsistent:
Perform anti-configuration of data or synchronize the entire table.
2.8.3 Snapshot Area Node Not Generated After Successful

Synchronization
Fault Symptom
The snapshot area node is not generated after successful synchronization.
Fault Cause
The client is not automatically refreshed or there is a system error.
Solution
1. Click the Refresh button, and then expand the NE nodes again to check whether the
snapshot area node is generated.
2. Check whether the UEP.CONFIGSET table has been generated from the snapshot
area data in the OMC database.
Ensure that the synchronization is successful. If synchronization is not required, the
files are not delivered, and the snapshot area is not refreshed/generated.
3. Check the log. If the snapshot area is not generated, error information is printed.
2.9 Global Faults

2.9.1 DST Configuration Error in the OMC
Fault Symptom
After the Daylight Savings Time (DST) is enabled, the alarm time in the OMC is incorrect,
and performance data is delayed.
Fault Cause
l The time zone setting of the OS is incorrect.
2-20

l The DST setting in the OMC is incorrect.
Solution
1. Set the time zone of the system properly.
For how to modify the time zone in different OSs, refer to Table 2-6.
Table 2-6 Time Zone in Ddifferent OSs
OS Time Zone Setting
Solaris In the /etc/TIMEZONE file, modify TZ=xxx,

and then restart the Solaris server.
xxx refers to a file in the /usr/share/li
b/zoneinfo directory. In the zoneinfo
directory, there are different folders for different
continents. The continent folders contain the
files that are named after cities. In the required
folder, find the file of the area.
For example, to set the time zone
to China, find the Asia folder in the
/usr/share/lib/zoneinf directory. In
the Asia folder, find Shanghai. Then, in the
/etc/TIMEZONE file, set TZ=Asia/Shanghai,
and restart the server.
Linux In the GUI window, select Applications >

System Settings > Date&Time > Time Zone.
In the time and time zone setting window that
is displayed, do not select the UTC option.
Windows Double-click the time at the right lower corner.

In the time and time zone setting window that
is displayed, set the time and zone.
2. In the OMC, set the DST.

Manage the DST settings of the NEs.
Select Configuration Management > Managed Element > Equipment > BBU >
Clock Device Set > Clock Device. Set correct Time zone, Daylight saving time
offset, Start time of daylight saving time, and End time of daylight saving time.
Daylight saving time offset refers to the difference between the DST and the normal
time. For example, if the DST is one hour earlier than the normal time, the DST step
is 1. If the step is 0, it means to disable the DST.
After the configuration is completed, start incremental synchronization. After the DST
is enabled, query the current time of the NE through the Dynamic Management
function.
2-21

2.9.2 The OMC Server Console Prompts FTP Boot Failure and File
Open Failure
Fault Symptom
The OMC server console prompts FTP boot failure and file open failure.
Fault Cause
The file exists in the log directory of the FTP server, but the user who logs into the system
has no right to read or write the file.
Solution
1. Exit the OMC server program.
2. Grant the user the rights to read and write the file that cannot be opened if the file is
an OMC version file.
3. Delete the file that cannot be opened if the file is a log file.
2.9.3 An EMS Client Failed to Start the OMMB NE Agent and Upload
Version Files
Fault Symptom
An EMS client fails to start the OMMB NE agent and upload version files.
Fault Cause
The OMMB client fails to compress the version files.
The OMMB client fails to upload the file package to the EMS.
Solution
1. Check whether any client of the OMMB server is running. If yes, close the client
process.
2. Delete the temporary files in the ums-clnt/temp and ums-clnt/deploy/runtim
e directories of the OMMB server.
Note:
You must delete the temporary files in the ums-svr/temp and ums-svr/deploy/r
untime directories before you restart the OMMB server.
4. Select the target NE agent on the EMS client, and start a forced upload.
2-22

Chapter 3
OS Faults
This section describes the typical faults of the OS and the handling methods.
Table of Contents
Solaris System Faults.................................................................................................3-1
Liunx System Faults ...................................................................................................3-3
3.1 Solaris System Faults

3.1.1 Abnormal Multi-Client Login After Abnormal Power-Off of the
SUN Server
Fault Symptom
After the SUN server is restarted, the textual interface instead of GUI is displayed.
Fault Cause
If this fault occurs, it indicates that the SUN server has been restarted abnormally.
Solution
Power off the SUN server and then restart it. Use stop+A to enter the OK mode. At the
OK prompt, run the boot -s command to enter the Signal User Model. Then, press the
Enter key. At the # prompt, run the pkgchk -f command to start fault repair. If the fault
repair process is normal, after fault repair is completed, run the init 3 (multi-user mode)
command to restart the system.
3.1.2 Incorrect NIC Device Name Causes Abnormal SUN Server

Network
Fault Symptom
After the SUN server is configured with an IP address, the NIC card fails to start normally,
and the ping to the NIC IP address fails.
Fault Cause
The NIC device name is different from the actual device name.
3-1

Solution
1. Run the dladm show-dev command. The current NIC devices and statuses are
displayed.
2. Open the /etc/hostname.XXX file, and check whether the NIC device name that is
contained in the hostname file name is the same as that is displayed in the previous
step.
For example, the device names that are displayed in the previous figure are ce0 and
ce1. However, the file name is hostname.e1000g0, indicating that the NIC device
names are different. In this case, change the file name to hostname.ce0.
3. After the modification, restart the SUN server.
3.1.3 No GUI Available for Applications on SUN Server

Fault Symptom
In the Solaris OS, the Xwindow, Xlib, and XGraphics problems occur. When dbca, netca
and EMS are started, the GUI window fails to be started.
Fault Cause
The value of the environment variable DISPLAY is incorrect.
Before factory delivery, a value is set for DISPLAY in the profile. In the actual application,
change the value to the IP address of the GUI terminal. (If the server is directly connected
to a monitor, set the value to the IP address of the server. For a remote login through
Xmanager, set the value to the IP address of the remote client.) The format of DISPLAY
is as follows:
DISPLAY=GUI terminal IP address:0.0
If the IP address of a GUI terminal is 10.63.208.205,
DISPLAY=10.63.208.205:0.0
Solution
1. Run the xhost + command as the root user.
2. Switch to a user that uses the GUI. For example, use the dbca or netca command to
switch to the oracle user. The following takes the oracle user as an example.
$su - oracle
$DISPLAY=10.63.208.205:0.0
$export DISPLAY
3. Run the dbca or netca command. Then the GUI is displayed.
3-2

Chapter 3 OS Faults
3.2 Liunx System Faults

3.2.1 VNC Fails to Display the GUI
Fault Symptom
Virtual Network Computing (VNC) fails to display the GUI.
Fault Cause
The VNC service of Linux is abnormal.
Solution
1. In the /root/.vnc/xstartup file, remote the # signs before two rows: unset
SESSION_MANAGER and exec /etc/X11/xinit/xinitrc.
2. Restart vncserver.
#vncserver -kill :1
#vncserver
3.2.2 Incorrect Character Set After Modification of the i18n File

Fault Symptom
After modifying the character set that is configured in the i18n file, restart the server. Then,
use the locale command to check the character set setting. It is found that the character
set of the server is still incorrect.
Fault Cause
The configuration file of the root user is damaged.
Solution
1. Delete the hidden files in the /root directory.
Run the following commands as the root user:
#cd /root
#rm -rf .*
#cp /etc/skel/.bash_logout /etc/skel/.bash_profile /etc/skel/.bashrc /root/
2. Delete hidden files, and then change the character set in the /etc/sysconfig/i18n
file to GBK. Then, run the following command to validate the modification:
#. /etc/sysconfig/i18n
3. Use the locale command to check whether the character set is correct.
3-3

3.2.3 Cannot Open Linux Service Menu

Fault Symptom
On some server boards, cannot open Linux service menu.
Run the system-config-services command. The error information is displayed.
Fault Cause
When the krb5-telnet file is modified, the file name is modified.
Solution
Run the ls -la command to check whether the name of the krb5-telnet file in the /etc
/xinetd.d directory has been modified. Then, restart the server.
The command for modifying the file name:

mv Current file name New file name
3.2.4 Hosts File Changed After IP Address Modification and Server

Restart
Fault Symptom
After modifying the host name or IP address, restart the server. The IP address or host
name fails to be modified. This causes such failure as the failure in monitoring databases.
Fault Cause
After the IP address is modified through the GUI, the /etc/hosts file is overwritten by
the /etc/sysconfig/networking/profiles/default/hosts file. During the host
name modification, only the /etc/hosts file is modified, while the /etc/sysconfig/n
etworking/profiles/default/hosts file is not modified. Then, after the IP address
is modified, the hosts file is changed.
Solution
1. While modifying the IP address, set the host name through the GUI.
In the /etc/hosts, set the mapping between the host name and IP address.
If you find that the content of /etc/hosts and the content of /etc/sysconfig/net
working/profiles/default/hosts are different, use /etc/hosts to overwrite
/etc/sysconfig/networking/profiles/default/hosts.
2. To map one host name to multiple IP addresses, modify the /etc/hosts.conf file.
For example, the content of the hosts file is as follows:
3-4

Chapter 3 OS Faults
Figure 3-1 Contents of the hosts File
In the /etc/host.conf file, add a line multi on, see the following figure.
Figure 3-2 Modifying the host.conf File
3-5

This page intentionally left blank.
3-6

Chapter 4
Database Faults
This section describes the typical faults of the Oracle database and the handling methods.
Table of Contents
Failure in Creating Oracle Listening............................................................................4-1
OMC Fails to Start......................................................................................................4-1
Error Occurs in Testing the Local Net Service Name ..................................................4-2
Database Fails to be Connected.................................................................................4-3
4.1 Failure in Creating Oracle Listening

Fault Symptom
During the installation of the OMC software, it is prompted that the database fails to be
connected. Use the lsnrctl command to check the listening status, and it is found that the
listening status is abnormal.
Fault Cause
The host name configuration of the server is incorrect.
Solution
Check whether the host names are consistent. Modify the host names in /etc/hosts
and /etc/sysconfig/network to be the same, and then restart the server board.
4.2 OMC Fails to Start

Fault Symptom
The OMC fails to start, the test on the database connection fails, and the following error
message is displayed:
ORA-01034: ORACLE not available

ORA-27121: unable to determine size of shared memory segment
Linux Error: 13: Permission denied
Fault Cause
The Oracle installer fails to set a correct setuid.
4-1

Solution
1. Run the following commands:
$cd $ORACLE_HOME/bin
$chmod 6751 oracle
2. Restart the OMC server.
4.3 Error Occurs in Testing the Local Net Service Name

Fault Symptom
Errors occur in testing the listening and local net service names, and the error codes are
as follows:
TNS-12546: TNS:permission denied
TNS-12560: TNS:protocol adapter error
TNS-00516: Permission denied
Linux Error: 13: Permission denied
Fault Cause
The permission is not set properly.
Solution
1. Switch to the root user, and set the permission for the /var/tmp/.oracle directory.
#su -
#cd /var/tmp
#chown -R oracle:dba .oracle
#chmod -R 777 oracle:dba .oracle

2. Assign permission to the ORACLE_BASE directory.
Use the echo command to query the path specified by ORACLE_HOME.
#echo $ORACLE_BASE
If the /oracle/u01/app/oracle directory is displayed in the query result, then

assign proper permission to the directory.
#chmod –R 6751 /oracle/u01/app/oracle
4-2

Chapter 4 Database Faults
4.4 Database Fails to be Connected

Fault Symptom
The test on the database connection fails, and listening is abnormal. Use the lsnrctl status
command to check the listening status, and three listening processes are not in the ready
status.
Fault Cause
l The database instance is not started.
l Listening is abnormal.
Solution
1. Use the sys user to connect the database and judge whether the database instance
is started.
#su -oracle
$sqlplus /nolog
SQL>conn sys/oracle as sysdba

If Connected to an idle instance is returned, it indicates that the database instance
is not started. Input
SQL>startup
If Connected is returned, it indicates that the database instance is started.
2. Check and ensure that the HOST value in the $ORACLE_HOME/network/admin/l
istener.ora file is the same as the host name in the /etc/hosts file.
4-3

This page intentionally left blank.
4-4

Glossary
DHCP
- Dynamic Host Configuration Protocol
EMS
- Element Management System
JMS
- Java Message Service
MAC
- Media Access Control
OMC
- Operation & Maintenance Center
OMCB
- Operation & Maintenance Center for Node B
OMMB
- Operation and Maintenance Module for BTS, NodeB and eNodeB
RNC
- Radio Network Controller
SNMP
- Simple Network Management Protocol
TCP
- Transmission Control Protocol
VNC
- Virtual Network Computing

ZTE-LTE Troubleshooting Guide

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

ZTE-LTE Troubleshooting Guide

Загружено:

Авторское право:

Доступные форматы

ZXSDR OMMB

Revision No. Revision Date Revision Reason

R1.0 2013-08-30 First Edition

Serial Number: SJ-20130704144811-009

Publishing Date: 2013-08-30 (R1.0)

SJ-20130704144811-009|2013-08-30 (R1.0) ZTE Proprietary and Confidential

Chapter 2 OMC Software Faults................................................................ 2-1

SJ-20130704144811-009|2013-08-30 (R1.0) ZTE Proprietary and Confidential

Chapter 3 OS Faults ................................................................................... 3-1

Chapter 4 Database Faults ........................................................................ 4-1

SJ-20130704144811-009|2013-08-30 (R1.0) ZTE Proprietary and Confidential

Prerequisite Skills and Knowledge

What Is in This Manual

1, Overview Describes the ZXSDR OMMB troubleshooting flow and common

SJ-20130704144811-009|2013-08-30 (R1.0) ZTE Proprietary and Confidential

| Separates individual parameters in a series of parameters.

Danger: indicates an imminently hazardous situation. Failure to comply can

Warning: indicates a potentially hazardous situation. Failure to comply can

Caution: indicates a potentially hazardous situation. Failure to comply

Note: provides additional information about a certain topic.

SJ-20130704144811-009|2013-08-30 (R1.0) ZTE Proprietary and Confidential

1.1 Troubleshooting Flow

Figure 1-1 Troubleshooting Flow

You can collect fault information in the following four ways:

à Analysis on traffic statistics indexes

SJ-20130704144811-009|2013-08-30 (R1.0) ZTE Proprietary and Confidential

à Abnormalities that are found in routine maintenance or health check

1.2 Common Maintenance Methods

SJ-20130704144811-009|2013-08-30 (R1.0) ZTE Proprietary and Confidential

Alarm and Operation Log Query

Table 1-1 OMC Log Location and Usage

Type Location Usage

GC logs The files similar to gc-09-05-27-16-06-52.log in They are used to troubleshoot

SJ-20130704144811-009|2013-08-30 (R1.0) ZTE Proprietary and Confidential

SJ-20130704144811-009|2013-08-30 (R1.0) ZTE Proprietary and Confidential

Path for diagnosis and resolution template: \ums\ums-svr\sdrmanager\sdrmanager

Select two or more items for diagnosis.

Table 1-2 Diagnosis Item and Analysis

Diagnosis Result Analysis

SJ-20130704144811-009|2013-08-30 (R1.0) ZTE Proprietary and Confidential

Diagnosis Result Analysis

An error code is Contact the ZTE technical support.

SJ-20130704144811-009|2013-08-30 (R1.0) ZTE Proprietary and Confidential

2.1 Fault Causes

For the common device management faults, refer to Table 2-1.

SJ-20130704144811-009|2013-08-30 (R1.0) ZTE Proprietary and Confidential

Table 2-1 Common Device Management Faults

Category Common Causes

Configuration l Incorrect data configuration or data verification failure causes the

Global faults l Improper configuration of rights leads to unavailability of some

SJ-20130704144811-009|2013-08-30 (R1.0) ZTE Proprietary and Confidential

2.2 Installation and Upgrade Faults

2.2.2 OMM Pre-installation Failure

SJ-20130704144811-009|2013-08-30 (R1.0) ZTE Proprietary and Confidential

2.2.3 Configuration Fails During Installation

2.2.4 Configuration Center Fails to Obtain the Configured IP

SJ-20130704144811-009|2013-08-30 (R1.0) ZTE Proprietary and Confidential

2.3 Communication Faults

SJ-20130704144811-009|2013-08-30 (R1.0) ZTE Proprietary and Confidential

2.3.2 Server Keeps on Printing "CODE = 10002" Error Messages

2.3.3 Topology Tree Link Status Is Different From Actual Link

SJ-20130704144811-009|2013-08-30 (R1.0) ZTE Proprietary and Confidential

2.3.4 Database Probe Prompts the Attempt to Set Up a TCP Link

2.3.5 Link Broken Alarm Caused by IP Address Conflict