LMT Processes

LMT Processes
The LMT and the OMU work in C/S mode. The LMT, serving as the client, provides an OM interface.
The LMT provides various GUIs for operations. You can perform ME management and maintenance
operations through the GUIs. The LMT provides the following functions in Table 1.
Table 1 LMT Processes Function description
Function Name Function Description
MML command The LMT provides a graphical MML command interface. To perform configuration
and maintenance operation on an ME, you can enter MML commands and
parameters on the MML command interface of the ME to send them to the OMU. If
you log in to the LMT in offline mode, you can run MML commands on the LMT to
edit MML batch processing files.
Device panel The device panel provides three functions: device management, board installation,
and module management. Generally, the device panel is used during routine
maintenance. It enables you to check the system running status, board running
status, and process running status on the interface of the client, instead of observing
the actual device.
Alarm The alarm subsystem of the LMT displays clear and correct alarm information in real
management time. You can query, browse, and manage alarms through the LMT alarm system.
Alarm information includes alarm names, alarm generation and recovery time, alarm
severity, fault location information, and alarm recovery suggestions.
Tracing This function enables the LMT to provide the following functions for fault analysis
management and location: signaling tracing, interface tracing, subscriber tracing, and message
interpretation. You can use these functions to trace the call connection processes,
status transition, resource utilization, number sending, control message streams of
terminals, trunk circuits, signaling links, and interface protocols in real time. The
tracing information can be retained for future reference.
Monitoring This function enables the LMT to display the CPU usage, memory usage, disk
management usage, and traffic through the port. This function also enables the LMT to monitor
the status of the OMU server. In addition, this function moves files from a specified
memory to the OMU.
FTP Through FTP, files can be transmitted between the LMT and the OMU server, such
as software packages, license files, and the running logs of the OMU and host. The
FTP transmission complies with the Secure Socket Layer (SSL) protocol.
SOL Serial Over LAN (SOL) is used to redirect the serial port on a board by using
the BMC so that the serial port messages can be transmitted over IP. SOL is
applicable to the maintenance of X86, MIPS (Million Instructions Per Second) and
switch boards. SOL supports operations such as copying, pasting, and automatically
saving information and scrolling the screen to view information. It does not support
graphical output.
Telnet The Telnet function of the LMT enables you to connect to the Telnet server to
perform maintenance and management operations. For example, you can connect
to the Telnet server to operate the LAN switch.
PuTTY By logging in to the PuTTY, you can log in to the Linux OS on a board and run shell
commands to perform maintenance on the board, such as starting OMU services.
Alarm box tool The alarm box tool receives alarm information from the OMU, converts the alarm
information, and then sends the converted alarm information to the alarm box
through the serial port. After receiving the alarm information, the alarm box
generates audible and visual alarms.
Tracing reviewer The tracing reviewer enables you to browse messages in a signaling message
tracing file. Through the tracing reviewer, you can query and analyze a message
tracing file. The file name extension of the message tracing file is .ptmf or .tmf.
The tracing reviewer enables you to resolve certain files whose file name extension
is .tmf and all files whose file name extension is .ptmf. The file name extension of
files for Union subscriber trace tasks is .tmf. However, these files cannot be
resolved by using the tracing reviewer. You can resolve the files by using the OSS.
PTMF2CAP tool The PTMF2CAP tool is used to convert the format of IP address tracing results. The
tool provides the following functions:
Convert one or more files from the .ptmf format to the .capfile.
Combine and convert multiple .ptmf or .cap files into one .cap file.
Combine and convert multiple .ptmf and .cap files into one .cap file.
Log information The log information collection tool on the LMT is an activity performed to collect the
collection tool on information about a faulty device for troubleshooting.
the LMT
LMT upgrade If the LMT connects to the OMU, and if the LMT detects that the version of
the LMT is inconsistent with that of the OMU, the LMTautomatically downloads the
correct LMT installation program from the OMU to the PC. After the LMT is
upgraded successfully, the system automatically restarts the LMT.
LMT Software Directories

Assume that the D:\HW iLMT path is selected for storing the installation files of the LMT during the
installation of the LMT. After the LMT is installed, the files related to the LMT are stored in the paths as
listed in the following tables. (Other paths for the files related to the LMT are similar.)
File paths
Table 1 describes the file paths of the LMT.
Table 1 File paths of the LMT
Path Description
D:\HW iLMT\omu The executable files and supporting files of the LMT.
D:\HW iLMT\uninstall The configuration files of the LMT for uninstalling

the LMT.
D:\HW iLMT\omu\workspace1\adaptor The configuration files and supporting files related to

the OMUversion.
D:\HW iLMT\omu\workspace1\alarmboxtool The executable files and supporting files of the alarm
box tool.
D:\HW iLMT\omu\workspace1\client The executable files and supporting files of the LMT,
which are not related to the OMU version.
D:\HW The executable files and supporting files of the log

iLMT\omu\workspace1\client\infogather collection tool of the LMT.
D:\HW The executable files and supporting files of the

iLMT\omu\workspace1\client\PTMF2CAP PTMF2CAP tool.
D:\HW The executable files and supporting files of the tracing

iLMT\omu\workspace1\client\tracereview reviewer.
Main files
Table 2 describes the main files.
Table 2 Main files
Path Description
D:\HW The startup file of the alarm box tool.

iLMT\omu\workspace1\alarmboxtool\alarm_box_tool.exe
D:\HW iLMT\omu\workspace1\client\lmt_client.exe The startup file of the LMT.
D:\HW iLMT\omu\workspace1\client\putty.exe The startup file of the PuTTY.
D:\HW iLMT\omu\workspace1\client\infogather\infogather.exe The startup file of the log collection

tool of the LMT.
D:\HW The startup file of the PTMF2CAP

iLMT\omu\workspace1\client\PTMF2CAP\PTMF2CAP.exe tool.
D:\HW The startup file of the tracing

iLMT\omu\workspace1\client\tracereview\trace_review.exe reviewer.
D:\HW iLMT\omu\workspace1\client\tracefile The running logs of the LMT.
OMU Work Mode

Networking
IP Addresses of the Host
IP Addresses of the OMU
IP Addresses of the LMT
Networking
Figure 1 shows the position of the OMU in the network architecture. The OMU connects to the LMT and
OSS through the maintenance network port. The OMU connects to MEs through the internal network.
One OMU can manage multiple MEs and provide uniform OM ports for the MEs.
Figure 1 Position of the OMU in the network
IP Addresses of the Host

The internal network has Base and Fabric planes. Each plane contains two network ports. The four
network ports are represented by Base1, Base2, Fabric1, and Fabric2. The IP addresses of the network
ports are in the following network segments respectively: 172.16.x.x, 172.17.x.x, 172.18.x.x, and
172.19.x.x. The IP addresses of the network ports are determined by the subrack numbers and slot
numbers of the boards that house the network ports. For example, the IP address of the Base1 network
port is 172.16.(128 + subrack number).(slot number x 8). The IP addresses of other network ports can be
determined from this example. For example, for the board in slot 4 of subrack 0, the IP addresses of the
Base1, Base2, Fabric1, and Fabric2 network ports are 172.16.128.32, 172.17.128.32, 172.18.128.32, and
172.19.128.32 respectively. The subnet masks of the IP addresses of the four network ports are
255.255.0.0. The OMU uses only the Base1 and Base2 network ports to communicate with service
boards even though Fabric ports can be used for communication. The OMU manages the SWU board
using the Fabric plane.
IP Addresses of the OMU
The OMU board binds the preceding four IP addresses and the following IP addresses:
Floating IP addresses of the internal network: Floating IP addresses can be bound only to the active
OMU board. The host connects to the OMU board using the floating IP addresses of the internal
network, that is, 172.16.128.1, 172.16.128.2, 172.17.128.1, and 172.17.128.2, 172.18.128.1, and
172.19.128.1.
Floating IP addresses of the external network: The LMT uses the floating IP address of the external
network to connect to the OMU board. There is only one floating IP address of the external network,
which is planned by the carrier.
Physical IP address of the external network: The physical IP address of the external network is
optional, and it does not vary with the OMU switchover. You can use this IP address to connect the
standby OMU board.
IP Addresses of the LMT
You must connect the PC that hosts the local maintenance terminal (LMT) to the maintenance network
port. After you configure the floating IP address of the external network on the LMT, the LMT can
communicate with the OMU.
OMU Software Structure
The OMU software runs on the Linux operating system (OS) above the ATCA hardware platform requires
a database. The OMU communicates with the host through IP buses in ATCA subracks. The OMU
communicates externally through the LMT and WebUI. The LMT runs on the Microsoft Windows OS and
uses the OMU maintenance IP address to communicate with the OMU. The WebUI also uses the OMU
maintenance IP address to communicate with the OMU. After you enter the OMU maintenance IP
address in the address box of Microsoft Internet Explorer, you can log in to the WebUI and view
performance measurements and upgrade the system. Figure 1 shows the software structure.
Figure 1 Software structure
The software includes the host software marked in gray in Figure 1 and the background software marked
in yellow in Figure 1. The software is detailed in Table 1. The version information is included in the CDs
released with the version.
Table 1 Detailed software information
Classification Operating Database Application Software

System
Host Application Linux OS OMU Application software for

software software for database MON, SMU, IMU, and SRMU processes:
platform Monitors processes and determines
processes whether a process is active or standby.
For details about these processes, see
Platform Processes.
Application Linux OS OMU Application software for service

software for database processes. For details about service
service processes, see ME service process.
processes
Background Client Windows OS of - Applicant software for the LMT:

software applicant the following Used for local operation and
software versions: maintenance.
Microsoft Applicant software for the WebUI:
Windows XP Used for performance management
SP3 or later and system upgrade.
(32-bit)
Microsoft
Windows
2003 SP2 or
later (32-bit)
Microsoft
Windows
Vista (32-bit)
Microsoft
Windows 7
(32-bit)
Microsoft
Windows
2008 (32-bit)
Table 1 Detailed software information
Classification Operating Database Application Software

System
Microsoft
Windows 8
(32-bit/64-
bit)
Microsoft
Windows 8.1
(32-bit/64-
bit)
Applicant Linux OS OMU Server software for PM and CM. For

software for database details, see OMU Processes.
OMU boards
The Proton database is a lightweight relational database system developed based on the industry-leading
open database PostgreSQL. It inherits all PostgreSQL features and particularly enhances the following
features based on the OMU application requirements:
PL/SQL syntax adaptation and extension
High availability (HA)
Application programming interface (API) for clients
One-click backup and recovery
The Proton database is easy to deploy.
OMU Software Directories
Important Directories on the OMU Board
The OMU requires the Linux OS, and the LMT requires the Windows OS. For routine maintenance,
you can access directories from the FTP client of the LMT, and then complete most OM tasks on
the LMT. Table 1 describes the directories on the FTP client.
Table 1 Directories on the FTP client
Directory on the FTP Client Directory on the OMU Server Descrip

tion
Software package (auto loading) /opt/pub/software/tmp Stores

(/opt/pub/software/tmp) version
package

tion
s,
upgrade
package
s, and
patch
package
s.
License file (/opt/pub/software/tmp) /opt/pub/software/tmp Stores

license
files.
ISO file (/opt/pub/software/tmp) /opt/pub/software/tmp Stores

software
package
s.
Memory dump file /opt/HUAWEI/cgp/workshop/omu/share/dm Stores

(/opt/HUAWEI/cgp/workshop/omu/share/dmp pmem the
mem) memory
dump
files.
Firmware file /opt/HUAWEI/cgp/workshop/omu/workspac Stores

(/opt/HUAWEI/cgp/workshop/omu/workspace e1/server/3rdTools/firmware firmwar
1/server/3rdTools/firmware) e files.
If the
OMU
has
been
upgrade
d,
workspa
ce1 may
change

tion
to
workspa
ce2.
ME file /opt/HUAWEI/cgp/workshop/omu/share/nefil Stores

(/opt/HUAWEI/cgp/workshop/omu/share/nefil e the files
e) customi
zed by
MEs.
OMU run log /opt/HUAWEI/cgp/workshop/omu/share/run Stores

(/opt/HUAWEI/cgp/workshop/omu/share/run_ _log/omu the
log/omu) running
logs of
the
OMU.
DEV log /opt/HUAWEI/cgp/workshop/omu/share/run Stores

(/opt/HUAWEI/cgp/workshop/omu/share/run_ _log/dev_log host
log/dev_log) logs.
DB log /opt/HUAWEI/cgp/workshop/omu/share/run Stores

(/opt/HUAWEI/cgp/workshop/omu/share/run_ _log/db_log databas
log/db_log) e logs.
OS log (/var/log) /var/log Stores

OS
logs.
Export file /opt/HUAWEI/cgp/workshop/omu/share/exp Stores

(/opt/HUAWEI/cgp/workshop/omu/share/exp ort files
ort) exporte
d by the
system,
includin
g

tion
perform
ance
measur
ement
results,
PCDRs,
CHRs,
and
alarms.
Device file /opt/HUAWEI/cgp/workshop/omu/share/devi Stores

(/opt/HUAWEI/cgp/workshop/omu/share/devi cefile device
cefile) files.
Release call record /opt/HUAWEI/cgp/workshop/omu/share/rele Stores

(/opt/HUAWEI/cgp/workshop/omu/share/rele asecall call
asecall) release
logs.
Backup /opt/HUAWEI/cgp/workshop/omu/share/bac Stores

(/opt/HUAWEI/cgp/workshop/omu/share/bac kup backup
kup) files.
Peer information /opt/HUAWEI/cgp/workshop/omu/share/pee Stores

(/opt/HUAWEI/cgp/workshop/omu/share/peer r_log the peer
_log) OMU
logs and
system
backup
informat
ion.
Installation log (/opt/pub/log) /opt/pub/log Stores

the
installati

tion
on logs
of the
operatin
g
system
and
other
software
.
Read-only ME file /opt/HUAWEI/cgp/workshop/omu/share/nefil Stores

(/opt/HUAWEI/cgp/workshop/omu/share/nefil e_readonly the files
e_readonly) of read-
only
MEs.
UA file /opt/HUAWEI/cgp/workshop/omu/share/om Stores

(/opt/HUAWEI/cgp/workshop/omu/share/omu uftp/ua/work the
ftp/ua/work) executio
n result
file.
Other important directories

Besides the directories that are described in Table 1, other important directories will be used during
emergency maintenance. For example, when you use PuTTY to log in to the OMU board to uninstall
the OMU, switch the network ports of the OMU, or restore the OMU database, you will use these
directories. Table 2 describes paths for these directories.
Table 2 Other important directories
Path Description
/opt/HUAWEI/cgp/uninstall Stores the script used to uninstall the OMU.
/opt/HUAWEI/cgp/version Stores all the software packages to load on

the OMU. You can run LST PKG to query
Table 2 Other important directories
Path Description
the information about software packages

that are loaded on the OMU.
/opt/HUAWEI/cgp/workshop/rollback Stores the script used to switch the

workspace of the OMU. The program files
of the OMU are stored in the workspace of
the OMU. The workspace of the OMU
cannot be switched through MML
commands if the OMU is running. Use the
script in this directory to switch the
workspace of the OMU. Only the root user
can run this script.
/opt/HUAWEI/cgp/workshop/nes/ne[ME ID] Stores the installation directory of a service

ME. You can query the ME ID by
running LST ME.
/opt/HUAWEI/cgp/workshop/omu/workspace[workspace Stores the work directory of the OMU. You

ID] can query the workspace ID by
running LST WKSP.
/opt/HUAWEI/cgp/workshop/omu/data Stores the data files of the OMU database.
OMU Processes
The operation and maintenance (O&M) system is made up of the following subsystems:
Common Service Unit (CSU): provides common services for system operations and provides
interfaces for controlling these services.
Device Interface Unit (DIU): converts the format of messages exchanged with devices.
Management Interface Unit (MIU): converts the format of messages exchanged with the
management system.
OMU: provides O&M functions.
Table 1 Modules of the O&M subsystems
Subsystem Module Name Module Name Function Description

(Acronym/Abbreviation) (Expansion)
OMU CM Configuration Used for data configuration. The CM

management module converts the data in the OMU
database into binary data and sends it to
the host.
FM Fault Manages faults for location and

management rectification.
PM Performance Collects and displays performance

management measurement data.
MM Maintenance Detects system status and maintains the

management system.
SM Security Provides the following functions:

management User and user group management
Command group management
User and user group rights
management
User authentication
The SM module also provides an
interface for querying user permissions.
MIT Management Queries the managed object instance

information tree tree and subscribes to or unsubscribes
from notifications of changes in
managed objects.
TM Tracing Implements the tracing function and

management provides an interface for reporting traced
service messages.
RMM Real-time monitor Manages status monitoring tasks and

management provides functions of querying and
reporting monitored status to the client.

DEVLOG Device log Records software running information in

text format in the log files of the client
and the OMU server.
BKM Backup Provides data backup management.

management
RSM Report server Resolves and sends performance data

management reports.
MIRROR Resource monitor Determines whether an OMU board is

active or standby, monitors resources of
active and standby OMU boards, and
synchronizes data between the active
and standby OMU boards.
OMUMONITOR Mirror monitor Monitors the Mirror module status.
MIU SOAP-AGT SOAP interface Provides a SOAP management

interface.
MMLSERVER MML interface Provides an MML management

interface.
LMTSERVER GUI client Provides a local O&M interface.

interface
SNMP-AGT SNMP Provides the SNMP northbound

northbound interface.
interface
WEB-AGT Web interface Provides an interface for logging in to

the OMU through WebUI.
CHK-AGT System Provides an interface for checking the

installation check system installation through WebUI.
interface

DIU SNMP-MGR SNMP Provides the device management

southbound function.
interface
DCM Device Manages and monitors communication

communication links between the OMU and MEs, and
management converts messages between the OMU
and MEs.
LOAD Loading Loads host programs and data files.

management
SNMP-MGRB Cooperation ME Manages third-party MEs.

management
CSU FTPS-SVC FTP service Provides the FTP and FTPS Server
services.
NTPS-SVC NTPS service Provides the NTP Server service.
NTPC-SVC NTPC service Provides the NTP Client service.
SYNC Log agent Collects dual-node synchronization logs

from the active OMU board and backs
up the logs to the standby OMU board.
UA User agent Schedules tasks and runs command

scripts at scheduled intervals.
LMT Login Failure

Symptom
Possible Causes
Fault Diagnosis
Procedure
Related Information
Symptom
When you start the client of HUAWEI Operation & Maintenance System, enter the correct user
name and password, and then click Login. Then, the system displays any of the following
messages:
Failed to initialize the communication environment. Check that the communication
security modes are consistent and the required services are running correctly, as shown
in Figure 1.
Figure 1 Failed to initialize the communication environment
Failed to communicate with the server. Please check if the network is connected or the
service is running properly, as shown in Figure 2.
Figure 2 Failed to communicate with the server
Failed to authenticate the ID certificate, or no algorithm matches the peer, as shown

in Figure 3.
Figure 3 Failed to authenticate the ID certificate, or no algorithm matches the peer
When you start the client of Huawei Operation & Maintenance System, enter the correct user name
and password, and then click Login. The login occasionally times out.
Possible Causes
The probable causes of the fault are as follows:
The network connection is interrupted.
The lmtserver module fails to run properly.
The security module fails to run properly.
The free disk space is insufficient.
A disk track is damaged.
The database connection is incorrect.
"Authenticate the peer" is enabled for the LMT, but the trust certificate is not configured for the LMT.
"Authenticate the peer" is enabled for the LMT, but the OMU certificate is still in the certificate
revocation list.
"Authenticate the peer" is enabled for the OMU (through the OSS), but the certificate is not
configured for the LMT.
The port (port 9101 or 11101) for logging in to the LMT is not enabled on the firewall.
Fault Diagnosis
Rectify the fault based on the error message returned by the system during the login.
Procedure
Rectify the fault based on the different error messages.
1. Rectify the fault based on the error message displayed during the login:
Failed to initialize the communication environment. Check that the communication
security modes are consistent and the required services are running correctly.: Go
to 2.
Failed to communicate with the server. Please check if the network is connected
or the service is running properly.: Go to 7.
Failed to authenticate the ID certificate, or no algorithm matches the peer.: Go
to 35.
Others: Go to 43
Check the configuration on the LMT.
2. Check whether the IP address of the Server is the same as the floating IP address of the
OMU board. For details on the IP address of Server, see Figure 4.
Figure 4 Login interface (1)
Yes: Go to 5.
No: Go to 3.
3. On the login interface, click the button on the right of Server, as shown in Figure 5.
The Server Management dialog box is displayed, as shown in Figure 6. Configure the
floating IP address of the OMU board as the IP address of the server, or change the IP
address of the server to the floating IP address of the OMU board.
Figure 6 Server Management dialog box (1)
4. Log in to the client again, and check whether the login is successful.
Yes: No further action is required.
No: Go to 5.
Check the network connection.
5. On the PC, choose Start > Run, and run cmd. The cmd.exe window is displayed.
6. Run ping IP address. Here, IP address indicates the floating IP address of the OMU board.
Then, check whether the network connection between the PC and the OMU server is normal,
that is, whether the output is consistent with that displayed in Figure 7.
Figure 7 Output of the ping command
Yes: Go to 11.
No: Go to 7.
7. Check whether the network cable of the PC is correctly connected.
Yes: Go to 9.
No: Go to 8.
8. Contact the network administrator to make sure that the network cable is connected correctly.
9. Check whether the IP address of the PC belongs to the same gateway as the floating IP
address of the OMU board.
Yes: Go to 11.
No: Go to 10.
10. Contact the network administrator to make sure that the IP address of the PC belongs to the
same gateway as the floating IP address of the OMU board.
11. Run telnet IP address Port number command in the cmd.exe window. (IP address indicates
the floating IP address of the OMU and port number is 9101 or 11101.) Check whether the
port is enabled on the server, as shown in Figure 8 and Figure 9.
Figure 8 Success of running the telnet command
Figure 9 Failure in running the telnet command
Yes: Go to 13.
No: Go to 12.
NOTE:
9101: Used for the LMT to set up connections with the OMU in ordinary mode.
11101: Used for the LMT to set up connections with the OMU in safety mode.
For the port information of the server, see OMU Communication Matrix in Security
Management Description.
12. Contact the customer to enable the port on the firewall, and then log in to the client again.
Then, check whether the login is successful.
No: Go to 13.
Check whether there are records that indicate IP addresses conflict.
13. Select a physical OMU IP address and log in to PuTTY as user root. For information about
how to use PuTTY, see PuTTY Operations.
14. Run QueryMirrorState and find the active OMU that is running in Active state, as shown
in Figure 10.
Figure 10 Current OMU status
15. Log in the active OMU board using PuTTY. After 5 minutes, check whether the information of
IP address conflict of the active OMU board is displayed, as shown in Figure 11.
Figure 11 IP address conflict
Yes: Go to 16.
No: Go to 18.
16. Contact the network administrator and check for fault based on the IP conflict information.
Then, replan the floating IP addresses of the OMU.
17. Use the new OMU floating IP address to log in to the client again. Check whether the login is
successful.
No: Go to 18.
Check whether the lmtserver module is running properly.
18. Log in to the PuTTY tool as user root using the physical IP address of the active OMU board.
For details about how to use the PuTTY tool, see PuTTY Operations.
19. Run su - omu to switch to user omu, as shown in Figure 12.
Figure 12 Switch user
20. Run status | grep -i lmtserver to check whether the system displays running, as shown
in Figure 13.
Figure 13 Check status
Yes: Go to 23.
No: Go to 21.
Start the lmtserver module manually.
21. Run svc_adm -cmd startsvc lmtserver and pid lmtserver in turn to check whether the
system displays running, as shown in Figure 14.
Figure 14 Check lmtserver module status
Yes: Go to 22.
No: Go to 43.
No: Go to 23.
Check whether the security module is running properly.
23. Log in to the PuTTY tool as user root using the physical IP address of the active OMU board.
For details about how to use the PuTTY tool, see PuTTY Operations.
24. Run su - omu to switch to user omu.
25. Run status | grep -i security to check whether the system displays running, as shown
in Figure 15.
Figure 15 Check status
Yes: Go to 28.
No: Go to 26.
Start the security module manually.
26. Run svc_adm -cmd startsvc security and pid security in turn to check whether the system
displays running, as shown in Figure 16.
Figure 16 Check security module status
Yes: Go to 27.
No: Go to 43.
No: Go to 28.
Check the disk space.
28. Run su - root and enter the password of user root to switch to user root.
29. Run df to check whether the disk usage is exactly 100%, as shown in Figure 17.
Figure 17 Check the disk space
Yes: Go to 30.
No: Go to 31.
30. Run cd /opt and du -h |grep -i [0-9]G > diskinfo.txt in turn, as shown in Figure 18 to record
the disk usage, and then go to 44.
Figure 18 Record the disk usage
Check whether damaged disk tracks are available.

31. Run badblocks -sv /dev/sda to check whether damaged disk tracks are available.
Yes: Go to 44.
No: Go to 32.
Check the database.
32. Run su - omu to switch to user omu.
33. Run dbopt -b db_status to check whether the output displays db_status :NORMAL, as
shown in Figure 19.
Figure 19 Check the database
Yes: Go to 34.
No: Go to 43.
No: Go to 43.
Configure the certificate.
35. Obtain the mapping identity certificate, trusted certificate, and revocation list from the
administrator of the OSS that manages the NE. Configure the certificate for the LMT. For
details, see Configuring a Digital Certificate for the OMU Client.
No: Go to 37.
Select SSL options on the LMT.
37. Select TLSv1 for Protocol Version and Medium for Algorithm Intensity. For details about
how to select SSL options, see Configuring the Secure Transmission Mode for the OMU
Client.
No: Go to 39.
Set the LMT login mode.
39. On the login interface, click the button on the right of Server, as shown in Figure 20.
The Server Management dialog box is displayed, as shown in Figure 21. Click Modify. In the
displayed Modify dialog box, select Common for Mode, as shown in Figure 22.
Figure 21 Server Management dialog box (2)

Figure 22 Setting the common login mode
No: Go to 41.
NOTE:
Use the Common mode only on internal networks because it is less secure than
the Security(SSL) mode.
Reinstall the LMT using the JWS.
41. Uninstall the LMT, or rename the installation directory of the LMT. Reinstall the LMT using the
Java Web Start (JWS). For details, see Installing the OMU Client.
42. Log in to the new client, and check whether the login is successful.
No: Go to 43.
Collect the log information, and contact technical support engineers.
43. Collect the following logs depending on the troubleshooting progress:
Client logs: The client logs are stored in the Installation path of the
client\omu\workspace1\client\tracefile directory. In addition, you can use the Log
information collection tool on the LMT to collect logs about the LMT for fault location.
OMU server logs: Use the Information Collection Tool to collect items in Common fault
analysis scenario.
44. Contact Huawei technical support engineers to rectify the fault.
The local maintenance terminal (LMT) is the local OM system of an NE. To facilitate operations, the
U2000 allows you to start the LMT of an NE in the topology view.
Before starting the LMT of an NE, install the correct LMT software for the desired NE on the
U2000 client.
The version of the LMT that is installed on the U2000 client must be consistent with that of the
NE software. Otherwise, starting the LMT will fail.
Before starting the LMT of an NE, install the correct LMT software for the desired NE on the U2000
client.
The version of the LMT that is installed on the U2000 client must be consistent with that of the NE
software. Otherwise, starting the LMT will fail.
OMU
This section describes the functions, networking, components, and features of the operation and
maintenance unit (OMU).
The OMU runs on the OMU board. The OMU provides an MML interface to manage and maintain the
system. For example, the OMUprovides the management and maintenance of data required for system
operation, performance measurement data, and alarm information. The OMU provides a set of operation
and maintenance (OM) functions and tools to help ensure uninterrupted system operation, lower
operating costs, and improve Quality of Service (QoS).
The OMU provides the following features:
Supporting HA
The OMU works in active/standby mode. It provides multiple levels of self-monitoring functions.
Using HA facilitates data backup and restoration and helps to maintain data security.
Client/server (C/S) mode
The OMU integrates the communication server with the database server. The OMU performs OM
tasks in C/S mode and supports simultaneous local or remote data configuration.
Human-machine interface
The OMU provides the ITU-T standard-compliant MML interface, visual graphical user interface
(GUI), and WebUI. The MML interface is used for data configuration and OM on the CGP. You can
use the GUI to help manage alarm information, trace messages, and interfaces, and observe device
operation status. The WebUI is used for performance measurement and system upgrade. In
addition, the WebUI implements the functions of the keyboard, video, and mouse switch (KVMS).
Extensibility
The OMU supports uniform management on multiple management elements (MEs), various
operating systems and databases, and various standard interfaces such as SNMP and SOAP.
The OMU is a distributed system that is developed on the basis of an object model.
Logging In to the OMU Client
Scenarios
Impact on the System
Prerequisites
Procedure
Additional Information
Scenarios
This section describes how to log in to the HUAWEI Operation & Maintenance System through the
local client.
NOTE:
You can start the HUAWEI Operation & Maintenance System through the OSS client to maintain the MEs
remotely. For details, see the OSS-related product documents.
This operation has no adverse impact on the system.
Prerequisites
Conditions
The prerequisites for logging in to the client are as follows:
Table 1 lists the hardware requirements for the hardware of the PC client.
Table 1 Hardware requirements
OS Minimum Configuration
Windows 8.1 (32- CPU frequency: 1 GHz

bit/64-bit) Memory: 1 GB for 32 bit, or 2 GB for 64 bit
Available disk space: The free disk space of the installation directory of
Windows 8 (32-bit/64-
the LMT client must be larger than 1 GB.
bit)
Windows 2008 (32-bit) CPU frequency: 1 GHz

Memory: 1 GB
Windows 7 (32-bit)
Available disk space: The free disk space of the installation directory of
Windows Vista (32-bit) the LMT client must be larger than 1 GB.
Windows XP SP3 or
later (32-bit)
Windows 2003 SP2 or

later (32-bit)
The client has been installed successfully. For details, see Installing the OMU Client.
The OMU server works normally.
Data
Before performing this operation, make sure that the following data is obtained from the system
administrator:
Floating IP address of the OMU server.
Account and password for local user to log in to the client.
Procedure
1. Start the client.
You can start the client in two ways:
Choose Start > Programs > HUAWEI Operation & Maintenance
System > HUAWEI Operation & Maintenance System.
Double-click the HUAWEI Operation & Maintenance System shortcut icon on the
desktop.
The Login dialog box is displayed, as shown in Figure 1.
Figure 1 Login dialog box
NOTE:
In the Login dialog box, click Offline to log in to the client in offline mode. In offline mode, it is
not necessary to specify User name, Password, Server, and User type.
In the Login dialog box, click Exit. Click Yes in the Confirm dialog box to exit
the Login dialog box.
2. Enter the user name in the User name text box, and password in the Password text box.
NOTE:
To set the user name memory policy, run SET CLTPOLICY in the MML Command - CGP window
of the client.
3. Select a server from the Server drop-down list. For information about how to add a server,
see Server Management.
4. Select a user type from the User type drop-down list.
User type consists of two types:
Local: Local users consist of user admin generated by default during initial installation of the
OMU, and other users created on the OMU client. Local users must pass the OMU
authentication.
EMS: Element management system users are the users created on the OSS client. The OSS
users must pass the OSS authentication.
5. Check whether a proxy server is used for the login.
Yes: Go to 6.
No: Go to 8.
6. Add the proxy server to the service list. For details, see 3 in Server Management.
7. In the Login dialog box, select Proxy server.
8. Click Login.
9. If you log in to the client for the first time, the Modify User Password dialog box is displayed, as
shown in Figure 2. Modify the initial password to log in to the client. For password requirements,
see the value range and the default parameter values in Table 1 of Configuring OMU User Security
Policies.
Figure 2 Modify User Password
10. If you use the client matching CGP V100 to log in to the OMU server matching CGP V200, the
system will display a message indicating that you need to reinstall the OMU client, as illustrated
in Figure 3. Click OK. The client automatically exits. Then, install the client matching CGP V200.
Figure 3 Warning message
11. If the ME version of the client is inconsistent with that of the server, the client prompts you to
upgrade the client software, as shown in Figure 4.
Figure 4 Confirm dialog box
Choose whether to upgrade the client software based on the actual conditions.
Choose Yes to upgrade the client software. After the client software is upgraded, switch to
the Login dialog box. Then, enter the password and log in to the client.
Choose No to forcibly log in to the client. The Forcible Login dialog box is displayed, as
shown in Figure 5. Select an ME version, and click OK to forcibly log in to the client.
Figure 5 Forcible Login
Related tasks
You can log out of the client in three ways:
Click on the toolbar. The Confirm dialog box is displayed. Click OK.
Choose System > Logout. The Confirm dialog box is displayed. Click OK.
Press Ctrl+G. The Confirm dialog box is displayed. Click OK.
You can exit the client in three ways:
Choose System > Exit. The Confirm dialog box is displayed. Click OK.
Click on the upper right of the client. The Confirm dialog box is displayed. Click OK.
Logging In to the OMU Client in Offline Mode

Scenarios
Prerequisites
Procedure
Scenarios
This section describes how to log in to HUAWEI Operation & Maintenance System in offline mode when
the OMU server is faulty or does not need to be connected.
The following operations are available when you log in to the client in offline mode:
Querying the window for setting message tracing parameters.
Configuring basic attributes of the client, such as system configurations and certificate
configurations.
Querying the help information, including the help information about the MML command, alarm and
event, and Graphical User Interface (GUI).
Editing the MML command scripts and saving the scripts to the local PC. This function enables you
to directly run the scripts when you log in to the client next time. The function, however, is available
only when you log in to the client in offline mode.
Prerequisites
Conditions
The client has been installed successfully.
Data
Data preparation is not required for this operation.
Procedure
1. Start the client.
You can start the client in any of the following ways:
Choose Start > Programs > HUAWEI Operation & Maintenance System > HUAWEIOperation
& Maintenance System.
Double-click the shortcut icon of HUAWEI Operation & Maintenance System on the
desktop.
The Login dialog box is displayed, as shown in Figure 1.
Figure 1 Login dialog box
2. Click Offline. The Select Version dialog box is displayed, as shown in Figure 2.
Figure 2 Select Version dialog box
You can log in to the client in offline mode in any of the following ways:
In the Select Version tab page, choose Platform Version and Product Version for offline login.
NOTE:
Click Select All to select all product versions.
Click Deselect All to clear all product versions.
In the History Login ME tab page, choose information from the historical login information, as
shown in Figure 3.
Figure 3 History Login ME tab page
NOTE:
Select the office to log in to from the drop-down list box.
The version information about the selected ME is displayed under the check box.
Click Delete Office to delete the selected history office information.
Click Delete All to delete all history office information.
In the History Login ME tab page, choose information from the history login information.
Select the office to log in to from the drop-down list box in the History Office area.
NOTE:
The Platform Version chosen in the Select Version tab page must be consistent with the
office you selected. Otherwise, MML commands will become unavailable.
The version information about the selected ME is displayed under the check box.
3. Click OK to log in to the client in offline mode.
Related Tasks
You can log in to the client again in offline mode in three ways:
Choose System > Login. The Confirm dialog box is displayed. Click OK.
Press Ctrl+G. The Confirm dialog box is displayed. Click OK.
You can exit the client in offline mode in three ways:
Choose System > Exit. The Confirm dialog box is displayed. Click OK.
Click on the upper right of the client. The Confirm dialog box is displayed. Click OK.
Related Concepts
None.
Introduction to the OMU Client GUI
Title Bar
Menu Bar
Toolbar
Navigation Pane
Output Window
Status Bar
MML Parameter Input Pane
MML Command Input Pane
MML Result Display Pane
After you log in to the client, the MML command navigation tree and the MML command window are
displayed by default.
Figure 1 shows the client GUI.
Figure 1 Client GUI
1 Title Bar 2 Menu Bar 3 Toolbar 4 Navigation Pane 5 Navigation Tab
6 Output Window 7 Status Bar 8 Parameter Input Pane 9 Command Input Pane 10 Result Display Pane
NOTE:
The MML window is composed of the MML Command tab, the MML Commandnavigation tree
pane, MML Parameter Input Pane, MML Command Input Pane, and MML Result Display Pane.
By default, the system opens the last activated MML command window. The MML command -
CGP window is displayed in either of the following conditions: (1) The client is logged in for the first
time. (2) The last activated ME is deleted.
When you log in to the client in offline mode, the MML command window is available. The ME list
displays the ME type and ME version.
In the MML Command navigation tree, you can open an MML command window of a certain ME
from the ME drop-down list box. The ME list can be automatically refreshed in real time.
Title Bar
The title bar is composed of the server name, client name, and the current window name, for
example, [MM2:10.1.6.210]HUAWEI Operation & Maintenance System-[MML Command
- CGP[MEID=0, MENM=Site Management]].
Menu Bar
The menu bar is composed of six menus: System, Maintenance, Alarm, View, Window,
and Help. Table 1 lists the functions of each menu.
Table 1 Functions of each menu
Menu Function Remark
System To configure system settings, lock settings, security When you log in to the system
management, and server management. offline, Lock and Security
Management are unavailable.
Maintenance To implement maintenance settings such as output When you log in to the system
settings, timeout settings, operations of saving offline, Scheduled Tasks, File
commands, scheduled tasks management, file transfer Transfer Service, and Batch
service, and operations of the batch processing Commands are unavailable.
commands.
Alarm To provide alarm management function such as alarm When you log in to the system offline,
browse, alarm log query, and alarm box operation. all menu items under Alarm are
unavailable.
View To display or hide the navigation tree, output window, When you log in to the system
debug pane, software debug pane, and object navigation offline, Debug, Software
tree. To open the WebUI login window. Debugand Web User Interface are
unavailable.
Window To specify the window display mode and record the -

opened windows.
Help To display the help information and version information -

about the product.
NOTE:
Choose View > Web User Interface from the menu bar. The client opens the WebUI login window
through the Microsoft Internet Explorer. If the Microsoft Internet Explorer is unavailable, the system
uses the default Microsoft Internet Explorer to open the window but the window is not of the default
size. This function is unavailable if no browser is installed.
Choose Help > About from the menu bar. The About dialog box containing the information such as
name and version of the product, is displayed.
Toolbar
The toolbar provides shortcut icons that have the same functions as the corresponding menus. Table
2 lists the functions of each shortcut icon.
Table 2 Functions of each shortcut icon
Shortcut Icon Function Shortcut Icon Function
To exit the system. To open the WebUI login window.
To log out of the system (in the To browse the real-time alarms.
normal state).
To log in to the system (in the
offline state).
To lock the system. To query the alarm log.
To close or open the MML To display the Alarm Box

Command window. Control dialog box.
To display or hide the To print the alarm real-time

navigation tree pane. information.
To display or hide the output To display the Documentation

pane. Centerwindow.
Navigation Pane
The navigation pane is on the left of the client and consists of several tabs. After you log in to the system,
the Maintenance tab, Device Panel tab, and MML Command tab are displayed by default. Table 3 lists
the functions of each tab page in the navigation pane.
Table 3 Functions of each tab page in the navigation pane
Tab Page Function
Maintenance It is divided into four services, including Tracing, Monitoring, SOL, and Telnet.
Tracing: To trace protocol messages.
Monitoring: To provide the function of monitoring the hardware of the equipment
or data-related measurement entities, and then displays the status of current
records through the graphic interface.
Serial Over LAN (SOL): To provide the function of connecting to each type of
board and perform remote maintenance operations.
Table 3 Functions of each tab page in the navigation pane
Tab Page Function
Telnet: To connect to the Telnet server to perform maintenance and

management operations.
Device Panel To provide a simulated panel of the equipment for monitoring the running status of the
equipment and managing configuration of the equipment.
MML Command To provide the hierarchical structure of MML commands and the system configuration
management for easy search and use of the MML commands.
Output Window
By default, Output Window is not displayed after the login. To open Output Window, click on the
toolbar or choose View > Output Window from the menu bar.
Output Window is composed of two tabs, Common and Maintenance.
Common: To display the last successful login information, such as IP address for logging in to the
client, terminal type, time, and number of consecutive failure times before this login.
Maintenance: To display information about the operation & maintenance and the MML commands,
such as the MML commands entered by operators, the MML commands automatically executed by
the system, and the execution results returned by the system.
Status Bar
The status bar is on the lowest part of the client window. The status bar displays the running status of the
terminal. From left to right, the parameters on the status bar are as follows:
Login user: Displays the name of the user who logs in to the system.
Connection status: Displays the connection status between the client and the ME.
IP address of the server: Displays the IP address of the server that is connected to the operation &
maintenance client.
LOGO: Displays the logo of Huawei Technologies Co., Ltd.
MML Parameter Input Pane
Set the value of command parameters in the parameter input box.
The parameters in red are mandatory. Enter or select a parameter value.
The parameters in black are optional. Set values according to actual requirements.
Table 4 lists the functions of the shortcut icons in the parameter input pane.
Table 4 Functions of the shortcut icons in the parameter input pane
Shortcut Icon Description
Displays the next history command. If the current command is the last history
command or a new command, this icon is unavailable.
The shortcut key for displaying the next command is F8.
Displays the previous history command. If the current command is the first command
that is run after login or no command is run after login, this icon is unavailable.
The shortcut key for displaying the previous history command is F7.
Displays a parameter input pane (Enter the parameters in the command input area)
by using this shortcut icon or pressing Enter.
Runs a command.
The shortcut key for running a command is F9.
MML Command Input Pane

In the command input pane, enter commands as follows:
Enter one or more commands by using semicolons to separate the entered commands.
NOTE:
A maximum number of 20 commands can be entered at a time in the command input pane.
Copy commands from the notepad, and paste them in the command input box. For operations on
batch commands, see Batch Command Operations.
MML Result Display Pane
This pane contains three tabs, Common Maintenance, Operation Record, and Help Information.
Table 5 describes the three tabs of the result display pane.
Table 5 Tabs in the result display pane
Tab Description
Common Maintenance Displays the information returned after running the commands.
Operation Record Records all the commands entered earlier.
Help Information Provides detailed information about the functions, precautions, and the meaning of
each command.
Setting Basic Properties

Scenarios
Prerequisites
Procedure
Scenarios
After logging in to the client, the basic properties of the client can be set as required. The basic properties
of the client are maximum output lines displayed in the output pane, information display mode in the
output pane, time display format, date display format, automatic lock duration, and log level setting of the
client.
Prerequisites
Conditions
There are no special conditions for this operation.
Data
Data preparation is not required for this operation.
Procedure
1. On the menu bar of the client, choose System > System Settings to open the System Settingsdialog
box, as shown in Figure 1.
Figure 1 System Settings dialog box
2. Click the Output Window tab and set the required value of Maximum Output Lines for
the Common tab of the output pane. The default value is 500.
NOTE:
To automatically scroll the contents displayed in the output pane, select Automatically scroll to
the new message. This check box is selected by default.
When you position cursor over the text box of the parameter Maximum Output Lines, the value
range 30-3000 is displayed.
3. Click the Time tab to set the time format, as shown in Figure 2. Choose different time formats from
the Time Format drop-down list. The time is displayed in selected time format in the Appearance
Example area.
Figure 2 Time tab
4. Click the Date tab to set the date format, as shown in Figure 3. In Date Separator, select a date
separator for separating year, month, and date. Choose different date formats from the Date
Format drop-down list. The set date format is displayed in Date Example.
Figure 3 Date tab
NOTE:
In the Time and Date tab pages, set the time format and date format of the system, click Apply, and
then click OK. The system displays the following information: Restart the client to have your settings
take effect.
5. Click the Lock Settings tab, as shown in Figure 4. Select Automatically locked, and set the required
lock duration.
Figure 4 Lock Settings tab
NOTE:
Assume that a client is started. If no operations are performed on the client within a specified
duration (also called automatic lock duration), the system automatically locks the client. For
details, see Locking and Unlocking the Client. If the automatic lock duration is not required,
deselect the Automatically locked check box.
When you place the cursor over the text box of the automatic lock duration, the value range 1-
35000 is displayed.
In the Lock Settings tab page, Automatically locked is selected by default. The system
automatically locks the terminal after 3 minutes (default value).
Automatically locked can be selected only when you are online.
6. On the Log Level Setting tab page as shown in Figure 5, set Log Level as required.
Figure 5 Log Level Setting tab
Logs have four levels (arranged from low level to high level): INFO, DEBUG, WARNING, and ERROR.
INFO: records the detailed logs of the client for fault rectification. If the log is configured to this
level, the performance of the client will be affected.
DEBUG (default): records the debugging logs of the client.
WARNING: records the alarm logs of the client.
ERROR: records the abnormality logs of the client.
After a log level has been set, the file in \omu\workspace1\client\tracefile of the installation directory
of the client records the logs of the level and above in real time. You can use the Log Information
Collection Tool to collect these logs.
7. Click OK to complete the setting.
1. Lock the client.

Automatic lock
The client is automatically locked if no operation is performed on the client within a specified
period. For details about the lock settings, see 5 in Setting Basic Properties. Figure 1 shows the
locked client.
Figure 1 Locking the client
Manual lock
The client can be locked manually by any of the following methods:
Click on the toolbar.

On the menu bar of the client, choose System > Lock.
Press Ctrl+Alt+M.
Figure 1shows the locked client.
2. Unlock the client.
If the client is locked, you must unlock it before performing operations.
a. Press Ctrl+Alt+U. The unlocking interface is displayed, as shown in Figure 2.
Figure 2 Unlocking the client
b. Enter the password, and click OK. The client is unlocked.
NOTE:
If you log in to the client, and the login password is modified, please use the modified password to
unlock the system.
1. Click the MML Command tab in the navigation pane. The MML Command pane is displayed on the
right side of the client.
2. Right-click the Common Maintenance pane or right-click the Command Input pane.
3. Choose Parameter Setting. The Parameter Setting dialog box is displayed, as shown in Figure 1.
Figure 1 Parameter Setting dialog box
4. Set the parameters. For information about parameter description, see Table 1. When the cursor is
placed on the parameter input boxes, the range of the parameter values are displayed.
Table 1 Parameter description
Parameter Value Range Description
Max.Operation Records 100-1000 Specifies the maximum number of

records that can be displayed in
the Operation Record tab page.
The default value is 400.
Max.Output Lines 100-10000 Specifies the maximum number of

lines that can be displayed in
the Common Maintenance tab
page.
Table 1 Parameter description
Parameter Value Range Description
Max.Redirection File Size 64-5120 Specifies the maximum size (in KB)
of a new MML command log file.
Command Sorting Selected or unselected Specifies whether to sort

commands in the command input
box in alphabetic order.
By default, this option is selected.
Common Maintenance Window Selected or unselected Specifies whether to automatically

Scrolling roll the information in the Common
Maintenance tab page.
Operation Record Window Locking Selected or unselected Specifies whether to switch to

the Common Maintenance tab
when the current displayed tab
page is Operation Record and
when you run a command or
double-click a node in the MML
command navigation tree.
By default, this option is unselected.
Enable the parameter hiding option Selected or unselected If this parameter is selected, you
can switch between common
parameters and more parameters
by clicking and in MML

Parameter Input Pane for certain
MML commands. If is grey, it

indicates that the parameters of the
command cannot be folded on the
GUI.
1. On the menu bar of the client, choose Maintenance > Save Commands. The Save Commandsdialog
box is displayed, as shown in Figure 1.
Figure 1 Save Commands dialog box
2. Save the successful commands and failed commands by checking the check box, click to select a
directory for saving the file, enter the file name, and click Save.
3. Click OK.
Introduction to the Device Panel

Device Management Navigation Tree
Simplified Panel
Information Display Area
The device panel consists of the device management navigation tree, simplified panel, and information
display area. If you log in to the client in offline mode, the device panel is not displayed.
Figure 1 shows the device panel. The T8280 subrack in the figure is for reference purpose only.
Figure 1 Device panel
1 Device Management Navigation Tree 2 Simplified Panel 3 Information Display Area
Device Management Navigation Tree

The device management navigation tree enables you to operate and maintain the rack, query the board
installation/loading progress, and manage modules.
Simplified Panel
After the rack, subrack, and board are added, the information about the rack, subrack, and board is
displayed on the simplified panel.
Information Display Area
The information display area is divided into four areas: Select ME, Select View, Legend, and Detail
Information.
After you select an ME from the ME drop-down list, the simplified panel displays all boards running
the ME processes. If you select ME A, the simplified panel displays only the boards running the
processes of ME A. If you add a board of the ME A type, the simplified panel displays the board only
after you add the processes of ME A to the board. The ME list is updated in real time, and the
default value is ALL. Select ALL to display all boards.
After the device panel is displayed, the device view is displayed by default. To switch to the
hardware view, click Hardware in the Select View area. After the software view is switched to the
hardware view, the board names appearing on the rack and subracks change from the application
type to the board physical type. After the hardware view is switched to the software view, the board
name changes from the board physical type to the application type. You can run LST BRD in
the MML Command - CGP window to query the application type and the board physical type.
The legend displays the mapping between the colors and the hardware status and module group
status of a board. The board color is determined by the hardware status, and the color of the status
indicator of the module group is determined by the process status of the board. For details,
see Table 1.
NOTE:
On the Advanced Telecom Computing Architecture platform, multiple modules (processes)
comprising a module group can be loaded on a single board.
Table 1 Status description
Category Color Status Description
Hardware Unknown This icon indicates the following conditions:

The OMU monitoring module does not
report the hardware status.
The client cannot identify the hardware
status reported by the OMU monitoring
module, or the time for hardware status

query performed by the OMU monitoring
module expires.
The board is not present or powered off.
The network is abnormal.
The communication between the client and
the OMU monitoring module fails.
Unconfigured The board is in the slot but not configured.
PowerOff The board is in the slot and configured, but

powered off.
Uninstalled The board is configured but not in the slot.
Fault The board is faulty.
LockedDisable The board is faulty and locked.
Active The active board works normally.
Normal The board in standalone mode works normally.
LockedEnable Only the active board is locked.
Standby The standby board works normally.
Module group Unknown This icon indicates the following conditions:

The OMU monitoring module does not
report the module status.
The client cannot identify the module group
status reported by the OMU monitoring
module, or the time for module status query
performed by the OMU monitoring module
expires.
The network is abnormal.
The communication between the client and
the OMU monitoring module fails.
Unassigned The module group is started but not assigned as

active or standby.
Inactive The board that the module group runs on is

locked.
Fault At least one process on the board is faulty.
Active The processes of a board (in standalone mode)

are normal, or the processes on the active board
(in active/standby mode) are normal.
Standby The standby processes on the standby board are

normal.
Not Ready The process on the board is being loaded and

cannot provide service.
1. In the navigation tree window of the client, choose the Device Panel tab to open the Device
Management navigation tree, as shown in Figure 1.
Figure 1 Device Management Navigation Tree
NOTE:
Right-click the Device Management node and choose Add Rack. Note that the Rack node is
displayed only when the rack is added. For details on how to add rack, see Rack Operations.
2. Double-click the Rack node under Device Management. On the right side of the Device
Management navigation tree, the simplified device panel (displaying front boards by default) is
generated, as shown in Figure 2. The information display area is also displayed, for details,
see Information Display Area. The T8280 subrack in the figure is for reference purpose only.
Figure 2 Simplified panel
1 Indicates the 2 Double-click 2 3 Displays the 4 Displays the scroll bar 5 Double- 6 Double-click 6 to
temperature in to switch status indicating the click 5 to switch to the back
a subrack. between the indicator of information about the display the emulation frame or
front boards and the module faulty board. The scroll emulation the front emulation
the back boards group on a bar is displayed only if a frame. frame in a
in a subrack. board. board in other racks is subrack.
faulty.
The simplified panel is described as follows:

As shown in Figure 2 (refer to 1) indicates the temperature of a subrack. The temperature value
depends on the temperature of the environment where the subrack resides and the operating
conditions of fans in the subrack. Figure 2 (refer to 1) indicates that the current temperature is
25C/77F. If the temperature is out of the normal range, the OMU reports ALM-3094 and ALM-
3095. For how to clear the alarms, see the corresponding handling procedures of ALM-3094 Fan
Temperature Exceeds Level 1 Threshold and ALM-3095 Fan Temperature Exceeds Level 2
Threshold.
To switch between the front boards and back boards, right-click 2 as shown in Figure 2 and
choose Switch Shelf Direction.
The status indicator of the module group is displayed when the front boards except for the switch
board house the process, as shown in Figure 2 (refer to 3). The color of the status indicator of the
module group on a board is determined by the process status of the board.
Double-click a rack node. If the boards in other racks are faulty (the boards on the device panel
are displayed in red), a scroll bar indicating the information about the faulty boards is displayed
under the simplified panel, as shown in Figure 2 (refer to 4). The scroll bar contains the information
such as subrack number, slot number, location, and application type (software view of the
simplified panel)/physical type (hardware view of the simplified panel) of a board. If a board, for
example, the back board USI0, does not have the application type, the scroll bar then displays the
physical type of the board. If there are multiple fault information records, the scroll bar separates
each record with space and displays the records in one line. For example, the first fault
information SRN=0,SN=15,LN=FRONT-SMU/SMM in Figure 2 indicates that the SMMboard in slot
15 of subrack 0 is faulty.
On the front view of the rack, right-click 5 as shown in Figure 2, and choose Open Front
Emulational Frame from the shortcut menu. The front view of the subrack is displayed. On the
rear view of the rack, right-click 5, and choose Open Back Emulational Frame from the shortcut
menu. The rear view of the subrack is displayed.
If the boards displayed on the panel are front boards, double-click 6 as shown in Figure 2 to
display the back emulation frame; if the boards displayed on the panel are back boards, double-
click 6 as shown in Figure 2 to display the front emulation frame.
Rack Operations
LST RACK is used to query the configuration information about a rack.
To query the information about all racks, do not specify any parameter.
To query the information about a specific rack, specify Rack number.
ADD RACK is used to add a rack.
During the new deployment or capacity expansion, you can use this command to add a rack.
RMV RACK is used to remove a rack data record.
The key parameter Rack number specifies a rack data record.
Note
Before a rack is removed, the subracks in the rack must be removed by running RMV SUBRACK.
This command is used for data commissioning by on-site engineers during deployment. During daily
maintenance, do not run RMV RACK.
MOD RACK is used to modify rack parameters, like Rack name, Room number, Row number,
and Column number.
ADD SUBRACK is used to add a subrack.
To add a subrack, you must run LST RACK to query if rack exists. Run ADD RACK to add a rack
before adding a subrack if no rack exists.
You must first add a basic subrack (subrack 0) first, and then add other subracks.
Front board type of switch board is SWU and Back board type of switch board is SWI.
SWU0/SWI0, SWU1/SWI0, SWUA0/SWIA0, SWUB0/SWI0, SWUB0/SWIA0, SWUB0/SWIB0.
RMV SUBRACK is used to remove a subrack data record.
You must remove all boards except the switch boards and SMM boards before removing a subrack.
A basic subrack (subrack 0) can be removed only after any other subracks have been removed.
To remove a narrowband central subrack, you must first remove all the narrowband slave subracks
first.
Modify Subrack (MOD SUBRACK)
NOTICE:
Running this command may affect services of the specified subrack. Exercise caution when deciding to
run this command.
MOD SUBRACK is used to modify or adjust configuration information (for example, Subrack
version, Slot number of RMU0 and Front board type of switch board) of a subrack.
LST SUBRACK is used to query a subrack.
To query the information about all subracks, do not specify any parameter.
To query the information about a specific subrack, specify Subrack number.
Reset Subrack (RST SUBRACK)
NOTICE:
This command will affect all services in the subrack. Exercise caution when deciding to run this
command.
RST SUBRACK is used to reset all front boards and TDM daughter boards in a specified subrack.
To improve the work efficiency, you can use this command to reset all front boards and TDM daughter
boards in a specific subrack in the following scenarios:
During initial deployment, capacity expansion, or version upgrade, you load the host software of a
new version to all the boards in a specified subrack.
During initial deployment, capacity expansion, or version upgrade, you modify parameters of the
operating system (for example, to modify the maximum tuple number) in a specified subrack.
After OMU restoration installation, you load the host software of the restored version to all the
boards in a specified subrack.
Note
This command is not used to reset the switch boards and the boards housing the OMU.
This command supports PFIA0, PFIB0, QXIA0, and QXIB0 board resetting when the entire subrack
is reset.
If a cross-subrack module (active module and standby module are not in the same subrack) is
present on a board in the subrack, ensure that the RMU module in basic subrack (subrack 0) runs
normally. Otherwise, the active/standby module cannot be confirmed by the RMU module.
If you reset the basic subrack (subrack 0), service failure in the entire office may occur.
If you reset the expansion subrack, service failure in the partial or entire office may occur.
This command supports role-based and domain-based management. You can run RST
SUBRACKonly when you have the operation right on the subrack.
To ensure secure and stable operation of the system, run RST SUBRACK during light-traffic hours
(for example, between 2:00 a.m. and 4:00 a.m.) unless in emergency.
Power Off Subrack (POF SUBRACK)
NOTICE:
This command will power off boards except for switch boards and SMM boards. Services in the specified
subrack will be terminated. Consult Huawei technical support engineers before running this command.
You can use this command to power off the subrack in the following scenarios:
To improve work efficiency, a new version of the host software must be loaded to all boards on a
subrack during a deployment, capacity expansion or upgrade process, you can use this command
and then use PON SUBRACK to power on the subrack.
To improve work efficiency, operating system parameter (like a maximum tuple number) in a
specified subrack must be modified during deployment, capacity expansion, or upgrade.
Note
If a cross-subrack module (active module and standby module are not in the same subrack) is
present on a board in the subrack, ensure that the RMU module of basic subrack (subrack 0) runs
normally, otherwise, the active/standby module cannot be confirmed by the RMU module.
If you power off the basic subrack (subrack 0), service failure in the entire office may occur.
If you power off the expansion subrack, service failure in the partial or entire office may occur.
To power off a subrack, the boards of the subrack will be powered off. The state of the boards
changes and stays in the power-off state eventually.
You can run this command to power off the subrack in which OMU boards are configured. After the
OMU board is powered off, the OMU client may not be able to connect to the OMU, and operations
may time out. If the OMU operates in active/standby mode and the active and standby OMU boards
are located in different subracks, you can use the currently active OMU board to power on the OMU
board which has been powered off. If the two OMU boards are located in the same subrack or the
OMU operates in standalone mode, you must remove and then insert the OMU board to power it on.
This command supports role-based and domain-based management. You can run POF
SUBRACK only when you have management rights on the subrack.
To ensure secure and stable operation of the system, run POF SUBRACK during light-traffic hours
(for example, between 2:00 a.m. and 4:00 a.m.) unless in emergency.
Power On Subrack (PON SUBRACK)

PON SUBRACK is used to power on a subrack.
You can use this command to power on the subrack that has been powered off by running POF
SUBRACK or the board that has been powered off by running POF BRD.
Note
This command is not used to power on switch boards or SMM boards that are located in the same
subrack as boards to be powered on.
To power on a subrack, the boards of the subrack will be powered on. The state of the boards
changes and stays in the power-on state eventually.
If no active and standby OMU board relationship is configured or the active and standby boards are
located in the same subrack (being powered off), you can power on an OMU board only by removing
and then reinserting the board.
This command supports role-based and domain-based management. You can run PON
SUBRACK only when you have management rights to power on subracks.
Board Management
Daughter Board
Daughter Board: Plug-on equipment plugs onto a plug-in equipment unit and is sometimes
referred to as a daughter board or child board. There are five types of daughter boards:
TDM(TDM): TDM daughter board. This type of daughter board must be installed on a SWUA1 or
SWUB1 board.
MRM0(MRM0): Daughter board of the media resource board, providing DSP channel resources.
This type of daughter board must be installed on an MPF0 board or on an MPF1 board.
AIC(AICA): ATM interface daughter board. This type of daughter board must be installed on a PFIA0
board.
EEC(EECA): Electronic Ethernet interface daughter board. This type of daughter board must be
installed on a PFIA0 board.
EFC(EFCA): Optical Ethernet interface daughter board. This type of daughter board must be
installed on a PFIA0 board.
List Daughter Board (LST DBRD)
Display Daughter Board (DSP DBRD)
Swap Daughter Board (SWP DBRD)
Reset Daughter Board (RST DBRD)
BMC
Deployed on boards, fan assemblies, and power entry modules (PEMs), baseboard management
controllers (BMCs) implements the following functions:
Collect, process, and store signals.
Monitor and maintain the running of boards, fans, and PEMs.
Provide hardware statuses and alarm information of the managed objects to shelf management
modules (SMMs) for equipment management.
Install, reset, and manage hardware without operating systems (OSs) by connecting to BMC ports
on the hardware.
Board Sensor
The command provided in this node is used to query the sensors of a board. A sensor is used to
monitor the CPU, the voltage and temperature of the board power module.
DSP SENSOR is used to query the operating status of sensors on a board.
Board RAID: The board RAID is an array of hard disks on a board.
DSP BRDRAID is used to query the operating status of the RAID on a board.
Boot Media
Boot media, including USB flash drives and compact flash (CF) cards, are used to start the operating
systems (OSs) of boards.
DSP HARDDISK is used to query the operating status of a hard disk on a board.
Note
When a board is not configured with any hard disk, or the board cannot be detected, the operating status
of the hard disk on the board cannot be obtained by running this command.
DSP BOOTMEDIA is used to query the running status of the boot media storages (USB flash card or CF
card) of the boards.
Note
When the system is started without any disks, some information of the boot media cannot be correctly
displayed.
Threshold
A threshold is an amount, level, or limit on a scale. When the threshold is reached, something else
happens or changes.
Function Description
The commands provided in this node are used to set and query thresholds at different levels for
generating alarms on CPU usage, storage space, and traffic over ports. These commands help users to
efficiently monitor the network running status.
LST ALMTHD is used to query configured alarm threshold of the CPU, storage space and port traffic.
MOD ALMTHD is used to modify alarm threshold of the CPU, storage space and port traffic volume.
Note
This command modifies the alarm threshold of the CPU or storage space only for the front board.
This command cannot modify the alarm threshold for CPU or storage space of the switch board and
the SMM board.
This command can only modify the port traffic alarm thresholds for the ports on the switch boards
and the ports on the LAN switches.
DSP CPU is used to query the CPU status.
LST PROCESS is used to query the configuration information on the process:
To query the information about the configuration information on all processes, do not specify any
parameter.
To query the information about the configuration information on a specific processes,
specify Subrack number and Slot number.
DSP PROCESS is used to display the configuration and state information on the process.
Note
Do not run this command on the switch boards.

During the command execution, the system consumes CPU resources of the host. To decrease the
consumption of CPU resources, you are advised to specify Subrack number or ME ID to query the
detailed information about a process.
Board
the OMU board maintains and manages the equipment and services in a single office.
Table 1 Mapping between MEs, board types, and application types
ME type Front Back Application Type

Board Board
Type Type
COMMON(COMMON) UPBA1 USI1 OMU: operation and maintenance unit. Functioning as

the local operation and maintenance unit, the OMU
UPBA1 USI7 board maintains and manages the equipment and
services in a single office.
UPBA1 USIA1
UPBA1 USIA7
UPBA2 USI1
UPBA2 USI7
UPBA2 USIA1
UPBA2 USIA7
UPBA5 USI1
UPBA5 USI7
UPBA5 USIA1
UPBA5 USIA7
UPBA6 USI1
UPBA6 USI7
UPBA6 USIA1
UPBA6 USIA7
UPB0 USI1
UPB0 USI6
UPB0 USI7

Board Board
Type Type
UPB1 USI7
GPU0 USI0
SWU0 SWI0 -
SWU1 SWI0
SWUA0 SWIA0
SWUA1 SWIA0
SWUA1 SWIA1
SWUB0 SWI0
SWUB0 SWIA0
SWUB0 SWIB0
SWUB1 SWIA0
SWUB1 SWIB0
SWUB1 SWIA1
SWUB1 SWIB1
SWU SWI
SMM -
CSCF(CSCF) UPBA0 USI1 CSSCU: session control unit. The SCU is the call
control process of the CSC3300. It
UPBA0 USIA1 performs SIP protocol
processing, Diameterencoding/decoding and protocol
UPBA0 USIA7 processing, call connection, service triggering, and
charging. In addition, the SCU process performs
UPBA0 USIB0 service logics of the P-CSCF, I-CSCF, S-CSCF,
and BGCF.
UPB0 USI1 CSCDB: central database. The CDB is the central
database process of the CSC3300. It maintains the
UPB0 USI6

Board Board
Type Type
GPU0 USI0 global data and subscriber distribution data of the

system.
CSBSU: broadband signaling unit. The BSU is the
signaling process of the CSC3300. It
terminates TCP/SCTPconnections,
encodes/decodes COPS/Diameter signaling, converts
the signaling into internal messages, and forwards the
messages to the SCU process.
CSDPU: dispatching unit. The DPU is the dispatching
process of the CSC3300. Functioning as an external
interface of the CSC3300, the DPU process receives
IP packets from the external system, forwards the
packets to corresponding BSU processes, and
forwards outbound IP packets to the external system.
CSDSU: dispatch and signaling unit. This type of
application is an integration of the DPU and BSU
modules. A board of this application type must be
configured with a back board.
CSISU: integrative session unit
(BSU+SCU+CDB+DPU). A board of this application
type can perform all the functions of the CSCF. Such a
board must be configured with a back board.
HSS(IMS-HSS) UPBA0 USI1 HSHIU: HSS integrative unit. This type of application is
an integration of all HSS modules.
UPBA0 USIA1 HSBCU: broadband signaling gateway and calling
control unit. A board of this application type
UPBA2 USI1 receives MAPservice signaling addressed to the HSS.
HSDPU: dispatching unit. The DPU module dispatches
UPBA2 USIA1 signaling for the HSS.
HSHCS: HSS control and signaling. A board of this
UPBA6 USI1 application type receives and processes signaling for
the HSS.
UPBA6 USIA1 HSSCS: SLF control and signaling. A board of this
application type receives and processes signaling for
UPB0 USI1 the SLF.
HSHMF: HSS management function. A board of this
GPU0 USI0 application type provides an interface to the service
provisioning system for the HSS.
ATS(ATS) UPBA0 USI1 ATMIB: mini-integrative session board. This type of

application is mainly applicable to the system that does
UPBA0 USIA1 not have a high demand for reliability or capacity. A
pair of UPB0 boards (active and standby) support 500
UPBA0 USIA7 thousand subscribers or 1380 kBHSA; a pair of UPBA0

Board Board
Type Type
UPBA0 USIB0 boards supports 1 million subscribers or 2760 kBHSA.

The quotation template for commercial deployment
UPB0 USI1 does not contain this application type.
ATISB: integrative session board. This type of
UPB0 USI6 application is an integrated deployment for a small-
capacity system. A pair of UPB0 boards supports 375
thousand subscribers or 1035 kBHSA; a pair of UPBA0
boards supports 750 thousand subscribers or 2070
kBHSA. For a system of small capacity, to fully utilize
the capabilities of the boards, you can configure the
service processes and dispatching processes on one
pair of boards. You must, however, control the number
of service processes on the boards to ensure the
performance of the dispatching processes.
ATCSB: call session board. This type of board is
deployed with only the services modules, namely, the
CCU and MSG. A pair of UPB0 boards supports 500
boards supports 1 million subscribers or 2760 kBHSA.
ATIFB: IP dispatch board. In a system of large
capacity, if this application type is deployed on an
UPB0 board, do not deploy any service modules on the
board; if this application type is deployed on an UPBA0
board, deploy only a small number of service modules
on the board. This helps to ensure the performance
and reliability of critical processes such as the
dispatching processes and at the same time fully utilize
the capabilities of the board.
ATISU: ATS integrative session unit.
ATSCU: ATS session control unit.
GPU0 USI0 ATMIB: mini-integrative session board. This type of

application is mainly applicable to the system that does
not have a high demand for reliability or capacity. A
pair of UPB0 boards (active and standby) support 500
The quotation template for commercial deployment
does not contain this application type.
ATISB: integrative session board. This type of
application is an integrated deployment for a small-
capacity system. A pair of UPB0 boards supports 375
boards supports 750 thousand subscribers or 2070
kBHSA. For a system of small capacity, to fully utilize
the capabilities of the boards, you can configure the

Board Board
Type Type
service processes and dispatching processes on one

pair of boards. You must, however, control the number
of service processes on the boards to ensure the
performance of the dispatching processes.
ATCSB: call session board. This type of board is
deployed with only the services modules, namely, the
CCU and MSG. A pair of UPB0 boards supports 500
ATIFB: IP dispatch board. In a system of large
capacity, if this application type is deployed on an
UPB0 board, do not deploy any service modules on the
board; if this application type is deployed on an UPBA0
board, deploy only a small number of service modules
on the board. This helps to ensure the performance
and reliability of critical processes such as the
dispatching processes and at the same time fully utilize
the capabilities of the board.
CCF(CCF) UPBA1 USI2 CFCCF: charging collection function.

The CCF receives the ACRs from IMS entities through
UPBA2 USI2 the Rf interface, processes the ACRs to generate the
CDRs, converts the CDRs into the format required by
UPBA5 USI2 each charging zone, and sends the final CDRs to the
charging zone.
UPBA5 USI8
UPBA6 USI2
UPBA6 USI8
UPB0 USI2
GPU0 USI0
RM(RM) UPBA0 USI1 RMPPU: protocol process unit. This type of application
establishes and maintains the signaling connections of
UPBA0 USIA1 the RM9000. It receives, dispatches, and
encodes/decodes signaling. It consists of the PPU and
NPU modules. The boards of this application type must
be deployed in conjunction with the boards of other
application types.
RMSPU: service process unit. This type of application
performs service control for the RM9000. It consists of
the SPU modules. One board can be configured with
up to four SPU modules. This type of application must

Board Board
Type Type

application types.
RMRPU: resource process unit. This type of
application manages and maintains the resources,
policies, charging rules, and routing data of the
RM9000. It consists of the RPU modules. The boards
of this application type must be deployed in conjunction
with the boards of other application types.
RMPIU: protocol integrative process unit. This type of
application establishes and maintains the signaling
connections of the RM9000. It dispatches and
encodes/decodes all the signaling. It consists of the
NPU, PPU, and SDU modules. The boards of this
application type must be deployed in conjunction with
the boards of other application types.
RMSDU: session distribution process unit. This type of
application dispatches messages for the RM9000. It
consists of the SDU modules. The boards of this
RMSRU: service resource process unit. This type of
application provides service control and manages and
maintains the resources, policies, charging rules, and
routing data of the RM9000. It consists of the SPU and
RPU modules. The boards of this application type must
application types.
RMIRU: integrative RMS unit. This type of application
controls the resources and policies of the RM9000. It
consists of the SPU, RPU, PPU, NPU, and SDU
modules. One IRU board can perform all the functions
of the RMS.
UPBA2 USI2 RMPDU: policy manager with database unit. This type
of application manages the device addresses of the
UPBA6 USI2 RM9000 PMS and issues the dispatching data to the
dpukernel (Dispatching Unit Working in the Kernel
Mode). It consists of the PAU modules.
UPB0 USI1 RMPPU: protocol process unit. This type of application

establishes and maintains the signaling connections of
UPB0 USI6 the RM9000. It receives, dispatches, and
encodes/decodes signaling. It consists of the PPU and
GPU0 USI0 NPU modules. The boards of this application type must
application types.

Board Board
Type Type
RMSPU: service process unit. This type of application

performs service control for the RM9000. It consists of
the SPU modules. One board can be configured with
up to four SPU modules. This type of application must
application types.
RMRPU: resource process unit. This type of
policies, charging rules, and routing data of the
RM9000. It consists of the RPU modules. The boards
of this application type must be deployed in conjunction
with the boards of other application types.
RMPIU: protocol integrative process unit. This type of
application establishes and maintains the signaling
connections of the RM9000. It dispatches and
encodes/decodes all the signaling. It consists of the
NPU, PPU, and SDU modules. The boards of this
RMSDU: session distribution process unit. This type of
application dispatches messages for the RM9000. It
consists of the SDU modules. The boards of this
RMSRU: service resource process unit. This type of
application provides service control and manages and
maintains the resources, policies, charging rules, and
routing data of the RM9000. It consists of the SPU and
RPU modules. The boards of this application type must
application types.
RMIRU: integrative RMS unit. This type of application
controls the resources and policies of the RM9000. It
consists of the SPU, RPU, PPU, NPU, and SDU
modules. One IRU board can perform all the functions
of the RMS.
RMPDU: policy manager with database unit. This type
of application manages the device addresses of the
RM9000 PMS and issues the dispatching data to the
dpukernel (Dispatching Unit Working in the Kernel
Mode). It consists of the PAU modules.
AIM(AIM) UPBA0 USI1 AIACU: access configuration unit. A board of this

application type allocates IP addresses to the UE and
UPBA0 USIA1

Board Board
Type Type
UPB0 USI1 stores the user profile of the NACFand UAAF for the P-
CSCF and RACF to query.
UPB0 USI6 AIISU: integrative session unit (ACU+LDB+BSU+DPU)
GPU0 USI0
UPBA2 USI1
UPBA2 USIA1
UPBA6 USI1
UPBA6 USIA1
UGC(UGC) UPBA0 USI1 UGUCG: universal control general. A board of this

application type performs message dispatching,
UPBA0 USIA1 protocol processing, gateway control, and data
management. It must be deployed in conjunction with
UPBA0 USIB0 the UGUCU or UGUCS to provide the functions of
the MGCF, gateway office, and tandem office entity.
UGUCU: universal control unit. A board of this
application type performs only the service functions. It
must be deployed in conjunction with the UGUCG to
provide the functions of the MGCF, gateway office, and
tandem office entity with comparatively large capacity.
This application type is often deployed on a UPB0
(front board).
UGUCS: universal control service. A board of this
must be deployed in conjunction with the UGUCU and
UGUCG to provide the functions of the MGCF,
gateway office, and tandem office entity with
comparatively large capacity. This application type is
often deployed on a UPB0 (front board).
UGUCF: universal control function. A board of this
application type is deployed in conjunction with the
UGUCG, UGUCU, and UGUCS to provide the
functions of the MGCF, gateway office, and tandem
office entity with large capacity. This application type is
UGMIU: minimum unit. A board of this application type
is an integrated deployment for a system of
comparatively small capacity. This application type is
deployed to provide functions of the MGCF, gateway

Board Board
Type Type
office, and tandem office entity. This application type is

UGBCU: basic control unit. A board of this application
type is an integrated deployment for a system of small
capacity. This application type is deployed to provide
office entity. The board can also be deployed in a
large-capacity system to perform message dispatching
and related service functions.
UGSBU: second basic control unit. For a large-
capacity system, the boards of application type are
deployed in conjunction with the UGBCU to provide
service functions of the MGCF, gateway office, and
tandem office entity.
UGTCU: extended control unit. A board of this
application type is often deployed in a large-capacity
system. It is deployed with the UGBCU and UGSBU to
function as an MGCF, a TMSC server, or a GMSC
server.
UPBA2 USI1 UGXPT: This type of application is required only when

the UGC3200 provides the protocol conversion
UPBA2 USIA1 function.
UPBA6 USI1
UPBA6 USIA1
UPB0 USI1 UGUCG: universal control general. A board of this

protocol processing, gateway control, and data
the UGUCU or UGUCS to provide the functions of the
MGCF, gateway office, and tandem office entity.
provide the functions of the MGCF, gateway office, and
(front board).

Board Board
Type Type

UGXPT: This type of application is required only when
the UGC3200 provides the protocol conversion
function.
UPB0 USI6 UGUCG: universal control general. A board of this

protocol processing, gateway control, and data
the UGUCU or UGUCS to provide the functions of the
MGCF, gateway office, and tandem office entity.
provide the functions of the MGCF, gateway office,
(front board).

Board Board
Type Type

MRFP(MRFP) MPF1 NIU0 MPMRP: multimedia resource processor. The MRFP is

a public network resource. It provides resource
MPF0 NIU0 services under the control of the MRFC. The resource
services include media stream mixing (multi-party
conference), playing of multimedia information
(announcement and streaming media),
and codec conversion.
MSOFTX(MSOFTX) UPBA0 ETIA0 MSX: The switch center on a mobile network. It

functions as the MSC server at the control layer of
ETIA2 the CS domain on the TD-SCDMA/WCDMA core
network. It implements functions such as call control
USI1 and connection management for voice and data
services that are based on IP or TDM.
USIA1
USIA7
USIB0
UPB2 ETIA0
ETIA2
USI1
USIA1
CSOFTX(CSOFTX) UPBA0 ETIA0 CSX: The softswitch center on a CDMA network. It

functions as a visited MSC (VMSC), VLR, SSP, GMSC,
ETIA2 and tandem MSC (TMSC). It implements the switch
function on the CDMA core network.
USI1
USIA1
UPB2 ETIA0
ETIA2

Board Board
Type Type
USI1
USIA1
MNB_IMS(MNB_IMS) MPF1 NIU0 MNAMR: assembled elements MR. A board of this

application type can house multiple network entities
MPF0 NIU0 such as the MRFP.
UPBA2 USI1 MNAEJ: assembled elements J. A board of this

UPBA2 USIA1 such as the HSS, USCDB, and ATS.
MNAEN: assembled elements N. A board of this
such as the OMU, SPG, and CCF.
MNAOM: assembled elements OM. A board of this
such as the OMU and SPG.
MNAHU: assembled elements HU. A board of this
such as the HSS and USCDB.
MNAEZ: assembled elements Z. A board of this
application type can house any network entities for
commissioning.
MNAEW: assembled elements W. A board of this
MNAER: assembled elements R.
MNAET: assembled elements T. A board of this
such as the HSS, USCDB, and ENS.
MNDES: ENS universal unit. This unit contains all the
functions of ENS and USCDB. That is, the MNDES is
used for signaling access and processing, and data
routing and storage.
MNAES: It refers to collocation of multiple MEs on one
board. A board can be deployed with the entities such
as the HSS, DNS/ENUM, and USCDB.
MNAHU3: assembled elements HU. The HSS and
USCDB can be deployed together on this board.
UPBA6 USI1 MNAEJ: assembled elements J. A board of this

UPBA6 USIA1 such as the HSS, USCDB, and ATS.

Board Board
Type Type

commissioning.
MNAER: assembled elements R.
ENSAU3: ENS integration board. A board of this
application type can be used to deploy the ENS and
USCDB (including physical database and in-memory
database).
UPBA2 USI2 MNAET: assembled elements T. A board of this

UPBA6 USI2 such as the HSS, USCDB, and ENS.
UPBA2 USI7 MNAEN: assembled elements N. A board of this

UPBA6 USI7 such as the OMU, SPG, and CCF.

Board Board
Type Type

UPBA2 USIA7 MNAEN: assembled elements N. A board of this

UPBA6 USIA7 MNAEN: assembled elements N. A board of this

database).
UPB0 USI1 MNAEJ: assembled elements J. A board of this

such as the HSS, USCDB, and ATS.

Board Board
Type Type

commissioning.
GPU0 USI0 MNAEJ: assembled elements J. A board of this

such as the HSS, USCDB, and ATS.
commissioning.
UPBA0 USI1 MNAET: assembled elements T. A board of this

UPBA0 USI2 such as the HSS, USCDB, and ENS.
UPBA0 USIA1 MNAER: assembled elements R. A board of this

such as the ATS and CSCF.
UPBA0 USIA7 MNAER: assembled elements R. A board of this

such as the ATS and CSCF.

Board Board
Type Type
UPBA2 USIB0 MNAHU: assembled elements HU. A board of this

UPBA6 USIB0 MNAHU: assembled elements HU. A board of this

database).
IPCTRX(IPCTRX) UPBA2 USI1 ETOSB: exclusive installation mode. This application

type is selected when a server of the ETAS9960
UPBA2 USIA1 selects the exclusive installation mode on
an ATCAUPBA2 board. This application type contains
UPBA6 USI1 the RedHat Linux AS 4.3 for 64-bit installation medium
and the tool kit, ETAS9960 software package,
UPBA6 USIA1 cooperation ME management NetSNMP software.
ETXMB: virtual machine installation mode. This
application type is selected when a server of the
ETAS9960 selects the virtual server installation mode
on an ATCA UPBA2 board. This application type
contains the RedHat Linux AS 4.3 for 64-bit installation
medium and the virtual machine kernel, virtual machine
template files, and the ETAS9960 software package.
UPB0 USI1 ETOSA: exclusive installation mode. This application

type is selected when a server of the ETAS9960
selects the exclusive installation mode on an ATCA
UPB0 board. This application type contains the RedHat
Linux AS 4.3 for 64-bit installation medium and the tool
kit, ETAS9960 software package, cooperation ME
management NetSNMP software.
ETXMA: virtual machine installation mode. This
application type is selected when a server of the
ETAS9960 selects the virtual server installation mode
on an ATCA UPB0 board. This application type
contains the RedHat Linux AS 4.3 for 64-bit installation
medium and the virtual machine kernel, virtual machine
template files, and the ETAS9960 software package.

Board Board
Type Type
MEDIAX(MEDIAX) UPBA2 USI2 MXMMU: multimedia unit. A board of this application

type provides the voice and video conference services,
UPBA2 USIA7 including the management of voice and video
conferences, conference scheduling, and conference
UPBA6 USI2 control. The MMU provides a Web portal to conference
subscribers and invokes the MRS to provide resources
UPBA6 USIA7 for voice and video conferences. Two such boards are
configured in 1+1 active/standby mode to improve
system reliability. The boards can be configured with or
UPB0 USI2
without disk array.
MXDCU: data conference unit. A board of this
application type provides the data conference service.
Such a board is installed on the Sametime (software
provided by IBM), which can provide services such as
desktop sharing, file sharing, browser sharing, and
electronic whiteboard. The data conference unit is an
internal module of the multimedia conference solution
provided by the MediaX3600. It must be deployed in
conjunction with the MXMMU.
MXWCU: The WEB conference unit is an internal
module of the MediaX3600 that provides data media
processing capabilities. Specifically, it provides
services such as desktop sharing, file sharing,
electronic whiteboard, and instant messaging.
UPBA2 USIA1 MXMMU: multimedia unit. A board of this application

UPBA2 USIB0 including the management of voice and video
UPBA6 USIA1 control. The MMU provides a Web portal to conference
UPBA6 USIB0 for voice and video conferences. Two such boards are
without disk array.
MXWCU: The WEB conference unit is an internal
module of the MediaX3600 that provides data media
processing capabilities. Specifically, it provides
services such as desktop sharing, file sharing,
electronic whiteboard, and instant messaging.
GPU0 USI0 MXMMU: multimedia unit. A board of this application

including the management of voice and video
control. The MMU provides a Web portal to conference

Board Board
Type Type

for voice and video conferences. Two such boards are
without disk array.
MXDCU: data conference unit. A board of this
application type provides the data conference service.
Such a board is installed on the Sametime (software
provided by IBM), which can provide services such as
desktop sharing, file sharing, browser sharing, and
electronic whiteboard. The data conference unit is an
internal module of the multimedia conference solution
provided by the MediaX3600. It must be deployed in
conjunction with the MXMMU.
SPG(SPG) UPBA1 USI1 SPSPG: service provision gateway. It is a functional

module of the SPG2800. Serving as a service
UPBA1 USIA1 provision gateway, the SPG2800 provides a universal
service provision interface and a Web portal to the
UPBA1 USIA7 service MEs.
SPXPU: service processing unit, a functional module of
UPBA1 USIB0 the SPG2800, improving service provisioning
performance of the SPSPG when the SPG2800 is
UPBA2 USI1 deployed in distributed mode.
SPRPG: RCS service distribution gateway and function
UPBA2 USIA1 module of the SPG2800. It is used to support the RCS
service to define soft terminals and distribute service.
UPBA2 USIA7
UPBA2 USIB0
UPB0 USI1
UPB0 USI3
UPB0 USI6
GPU0 USI0
UPBA5 USI1
UPBA5 USIA1
UPBA5 USIA7

Board Board
Type Type
UPBA5 USIB0
UPBA6 USI1
UPBA6 USIA1
UPBA6 USIA7
UPBA6 USIB0
ENUM_SERVER(ENUM_SERVER) UPBA2 USI1 ENSRV: exclusive installation mode. This application

type is applicable both the UPB0 and UPBA2 ATCA
UPBA2 USI3 boards. This application type is selected when the
cooperation ME ENUM selects the exclusive
UPBA2 USIA1 installation mode. This application type contains the
SuSE Linux installation medium and the tool kit, ENUM
UPBA6 USI1 software package, cooperation ME management
NetSNMP software.
UPBA6 USI3
UPBA6 USIA1
UPB0 USI1
USCDB(USCDB) UPBA0 USI1 USDPU: dispatching unit. This type of application

forwards IP packets. It receives and transmits
UPBA0 USIA1 messages for the USCDB. As an independent network
entity, the USCDB uses one IP address to
communicate with the outside. The internal modules
are identified by port numbers. The DPU works in
active/standby mode. One floating IP address is
configured on the external network interfaces of the
two DPU boards. A board of this application type is
used only for Huawei internal test. Do not use it on a
live network.
UPBA2 USI1 USDIU: 32-bit data integrated unit. A board of this

application type integrates the functions of the DRU,
UPBA2 USIA1 DSU, and physical data storage management. Such a
board is not configured with disk arrays. A board of this
UPBA6 USI1 application type is used only for Huawei internal test.
Do not use it on a live network.
UPBA6 USIA1 DIU64: 64-bit data integrated unit. A board of this

Board Board
Type Type
DSU, and physical data storage management. Such a

board is not configured with disk arrays.
USDRU: data route unit. A board of this application
type provides the data routing function. It stores the
route data and global data. The DRU can process the
requests for the global data and identify the DSU
cluster that stores the required subscriber data.
USDID: data integrated unit. A board of this application
type integrates the functions of the DRU, DSU, and
data storage device management. Such a board is not
configured with disk arrays. A board of this application
type is used only for Huawei internal test. Do not use it
on a live network.
USDID3: data integrated unit. A board of this
DSU, and data storage device management. Such a
USRSU: DRU and DSU unit. It is an integration of the
DRU and DSU.
USCAG: convergent access gateway. CAG is the
access point for third-party Value-Added Service (VAS)
systems to access the USCDB. It provides
standard LDAPinterfaces for third-party VAS systems
to access data in the USCDB.
USPGW: provision gateway. The PGW is a point for
the provisioning system to access the USCDB. It
performs operations on the USCDB according to the
instructions issued by the provisioning system. The
PGW operates and maintains the static data in the
USCDB database. The PGW can work in
active/standby mode.
UPBA2 USI2 USPMU: It refers to the provisioning system and data

management unit. PGW, the access point between the
UPBA6 USI2 provisioning system and the USCDB, converts
commands sent from the provisioning system as
operations on the USCDB. It provides the operation
and maintenance function for managing the statistic
data in the USCDB database and the physical storage
management function for storing data on disk arrays.
USPMU3: It refers to the provisioning system and data
provisioning system and the USCDB, converts

Board Board
Type Type

USDMU2: data management unit. The DMU manages
the data storage devices, that is, the disk arrays.
USPID3: The USPID3 boards are used for data
services and service provision. The data are stored on
the local hard disks.
UPBA2 USI3 USDIU: 32-bit data integrated unit. A board of this

UPBA6 USI3 DSU, and physical data storage management. Such a
board is configured with disk arrays. A board of this
UPB0 USI3 application type is used only for Huawei internal test.
Do not use it on a live network.
DIU64: 64-bit data integrated unit. A board of this
DSU, and physical data storage management. Such a
board is configured with disk arrays.
USDMU: data management unit. The DMU manages
USDMD: data management unit. The DMD manages
the data storage devices, that is, the onboard hard
disks. A board of this application type is used only for
Huawei internal test. Do not use it on a live network.
USDID: data integrated unit. A board of this application
type integrates the functions of the DRU, DSU, and
data storage device management. Such a board is not
configured with disk arrays. A board of this application
type is used only for Huawei internal test. Do not use it
on a live network.
USDID3: data integrated unit. A board of this
DSU, and data storage device management. Such a

Board Board
Type Type
UPB0 USI1 USDRU: data route unit. A board of this application

USDPU: dispatching unit. This type of application
messages for the USCDB. As an independent network
live network.
DRU and DSU.
access point for third-party VAS systems to access the
USCDB. It provides standard LDAP interfaces for third-
party VAS systems to access data in the USCDB.
UPB0 USIA1 USDRU: data route unit. A board of this application

DRU and DSU.

Board Board
Type Type

UPB0 USI2 USPMU: It refers to the provisioning system and data

GPU0 USI0 USDMU: data management unit. The DMU manages

USDPU: dispatching unit. This type of application
messages for the USCDB. As an independent network
live network.
USDMD: data management unit. The DMD manages
the data storage devices, that is, the onboard hard
disks. A board of this application type is used only for
Huawei internal test. Do not use it on a live network.
DRU and DSU.

Board Board
Type Type

USPMU: It refers to the provisioning system and data
UPBA2 - USDSU: data service unit. The DSUs are deployed in

several clusters to store the subscriber data. It can
UPBA6 - process operations received from the DRU, such as
querying, adding, deleting, and updating the subscriber
UPB0 - data. Each DSU clusters stores a portion of the
subscriber data according to the load balancing
principle. The DSUs within one cluster store the same
subscriber data and work in load-sharing mode.
GPU0 - USDSU: data service unit. The DSUs are deployed in

several clusters to store the subscriber data. It can
process operations received from the DRU, such as
querying, adding, deleting, and updating the subscriber
data. Each DSU clusters stores a portion of the
subscriber data according to the load balancing
principle. The DSUs within one cluster store the same
subscriber data and work in load-sharing mode.
USDRU: data route unit. A board of this application

Board Board
Type Type
UPBA7 USIA1 USRSU2: DRU and DSU unit. It is an integration of the

DRU and DSU.
UPBA2 USIB0 USRSU: DRU and DSU unit. It is an integration of the

DRU and DSU.
UPBA6 USIB0 USDRU: data route unit. A board of this application
UPBA2 USIA7 USRSU: DRU and DSU unit. It is an integration of the

DRU and DSU.
UPBA6 USIA7
SGSN-USN(SGSN-USN) MSPB0 PFIA0 EPU: enhanced packet forward unit. The EPU board
provides services related to the user plane.
MSPB0 XGIA0
UPBA1 USI7 CGW: Charging gateway server(Charging Gateway).

The CGW is a universal gateway between the switch
UPBA5 USI7 and the billing center. It buffers and preprocesses
CDRs. It provides powerful CDR storage and
conversion capabilities and interworks with the billing
center through FTP or GTP. Working in conjunction
with the switch, the CGW provides large-capacity
media for storing CDRs and provides charging
interfaces for the switch.
DNS: Domain name service processing unit (Domain
Name System). The DNS is used to translate domain
names into IP addresses. It can translate multiple
domain names at a time and supports recursive search
and active/standby synchronization.
UPBA3 ETIA0

Board Board
Type Type
UPBA3 SSIA0
UPBA3 SSIA1 ECU: enhanced control plane unit. The ECU board
performs services and charging functions related to the
UPBA3 SSIA2 control plane.
UPBA3 LFI
ESUA0 QXIA0 ESU: enhanced service processing unit. The ESU

board provides the services related to the control plane
ESUA0 ETIA0 and the user plane.
ESUA0 SSIA0
ESUA0 SSIA2
ESUA0 PFIA0
UFCB0 PFIA0 EPUB: enhanced packet forward unit. The EPUB

board provides services related to the user plane.
EVU: The Enhanced Value-added Unit (EVU) provides
an enhanced platform for processing value-added
services. It implements functions such as processing
value-added services such as CHRs, storing data, and
transferring data.
ESUB0 QXIB0 ESUB: enhanced service processing unit version B.

The ESUB board provides the services related to the
ESUB0 PFIB0 control plane and the user plane.
CSE(CSE) UPBA0 USI1 CEASU: AS service unit. A board of this application

type processes services such as Uniphone, Multiring,
UPBA0 USIA1 and Transfer and signaling such as SCCP, TCAP, and
MAP.
UPB0 USI1 CEADB: AS database unit. It maintains the global data
and subscriber distribution data of the system.
UPB0 USI6 CEBSU: broadband signaling unit. It terminates
TCP/SCTP connections. The BSU processes work in
GPU0 USI0 load-sharing mode.
CEDPU: dispatching unit. It dispatches IP packets. The
DPU processes work in active/standby mode.
CEDSU: dispatch and signaling unit. It is an integration
of the DPU and BSU processes.

Board Board
Type Type
CEISU: integrative session unit

(ASU+ADB+DPU+BSU)
IGWB(IGWB) UPBA1 USIA1 IGWB: iGateway bill. The IGWB provides the offline
charging function. Deployed with the IGWB processes,
UPBA2 USI1 the board can receive and process CDRs, convert the
CDR format, distribute CDRs to the billing center, back
UPBA2 USIA1 up the CDRs to a third-party server, and provide a Web
page for CDR browsing.
UPBA5 USIA1
UPBA6 USI1
UPBA6 USIA1
UPB0 USI1
UPB3 USIA1
SAE-HSS(SAE-HSS) UPBA0 USI1 SHHIU: HSS integrative unit. This application type is
UPBA0 USIA1 SHDPU: dispatching unit. A board of this application
type dispatches signaling for the HSS.
UPBA2 USI1 SHHCS: HSS control and signaling. A board of this
application type receives and processes signaling for
UPBA2 USIA1 the HSS.
SHHMF: HSS management function. A board of this
UPBA6 USI1 application type provides an interface to the service
provisioning system for the HSS.
UPBA6 USIA1 SHBCU: SAE-HSS broadband signaling gateway and
calling control unit.
UPB0 USI1
UPBA0 USIB0 SHHIU: HSS integrative unit. This application type is

UPBA2 USIB0
UPBA6 USIB0
UPBA0 ETIA0 SHHIU: HSS integrative unit. This application type is

UPBA0 ETIA2
UPBA0 SSIA0

Board Board
Type Type
UPBA0 SSIA1
UPBA2 ETIA0
UPBA2 ETIA2
UPBA2 SSIA0
UPBA2 SSIA1
UPBA6 ETIA0
UPBA6 ETIA2
UPBA6 SSIA0
UPBA6 SSIA1
UPB0 ETIA0
UPB0 ETIA2
UPB0 SSIA0
UPB0 SSIA1
UPB1 ETIA0
UPB1 ETIA2
OSG(OSG) UPBA2 USI2 OSMMU: A board of this application type provides

functions such as the attendant console and
UPBA2 USIA7 automated attendant. These functions facilitate the use
of Centrex services for enterprise subscribers.
UPBA6 USI2
UPBA6 USIA7
UPB0 USI2
GU-HLR-FE(GU-HLR) UPBA0 ETIA2 GUFEU: HLR signaling processing unit. This unit is
used for setup of connections with other mobile
UPBA0 USIA1 network entities and processing of signaling services,

Board Board
Type Type
UPBA0 ETIA0 such as MAP operations of call processing and

location registration. The GUFEU contains a signaling
UPBA0 SSIA0 access unit and a service processing unit.
UPBA0 SSIA1
UPBA2 ETIA2
UPBA2 USIA1
UPBA2 ETIA0
UPBA2 SSIA0
UPBA2 SSIA1
UPBA6 ETIA2
UPBA6 USIA1
UPBA6 ETIA0
UPBA6 SSIA0
UPBA6 SSIA1
UPB0 ETIA2
UPB0 USIA1
UPB0 ETIA0
UPB0 SSIA0
UPB0 SSIA1
UPB1 ETIA2
UPB1 USIA1
UPB1 ETIA0
UEIR(UEIR) UPBA0 ETIA2


Board Board
Type Type
UPBA0 USIA1
UPBA0 ETIA0
UPBA2 ETIA2
UPBA2 USIA1
UPBA2 ETIA0
UPBA6 ETIA2
EIRU: EIR signaling processing unit. This unit is used
UPBA6 USIA1 for setup of connections with other mobile network
entities and processing of signaling services, such as
UPBA6 ETIA0 MAP operations of CHECK_IMEI. The EIRU contains a
signaling access unit and a service processing unit.
UPB0 ETIA2
UPB0 USIA1
UPB0 ETIA0
UPB1 ETIA2
UPB1 USIA1
UPB1 ETIA0
UNP(UNP) UPBA0 ETIA2 UNPU: UNP signaling processing unit. This unit is
used for setup of connections with other mobile
UPBA0 USIA1 network entities and processing of signaling services.
The UNPU contains a signaling access unit and a
UPBA0 ETIA0 service processing unit.
UPBA2 ETIA2
UPBA2 USIA1
UPBA2 ETIA0
UPBA6 ETIA2
UPBA6 USIA1

Board Board
Type Type
UPBA6 ETIA0
UPB0 ETIA2
UPB0 USIA1
UPB0 ETIA0
UPB1 ETIA2
UPB1 USIA1
UPB1 ETIA0
CHR(CHR) UPBA1 USIA1 CHR: call history record.
UPBA5 USIA1
MNB_USC(MNB_USC) UPBA0 USIA1 MNUFE: integrated FEapplication type of SingleSDB. It

consists of the following application types:
UPBA0 USIA7 HSHCS application type of the HSS9820
FEU application type of the HSS9860
ENSFU application type of the ENS
In actual application, MNUFE is an integration of the
preceding two or three application types.
MNPCC: UPCC integrated service board. It consists of
the UPPDU application type and UPIRU application
type of the UPCC.
UPBA0 ETIA2 MNUFE: integrated FE application type of SingleSDB.

It consists of the following application types:
HSHCS application type of the HSS9820
UPBA2 USIA1 GUHGU: HLR universal unit. This unit contains all the
functions of the HLR FE and HLR BE. That is, the
UPBA6 USIA1 GUHGU is used for signaling access and processing,
and data routing and storage.

Board Board
Type Type
UPPGU: universal unit of UPCC. This unit contains all

the functions of the UPCC and USCDB. It is used for
logic processing for the policy and resource, and data
MNUFE: integrated FE application type of SingleSDB.
type of the UPCC.
MNRSU: SingleSDB FE application type with data
collectively deployed. It consists of the DRU and DSU
of multiple FEs.
MNGBA: application type with the BSF and AP
functions of the UIM collectively deployed. It consists of
the DRU and DSU of the BSF.
UPBA2 USIA7 MNUFE: integrated FE application type of SingleSDB.

UPBA6 USIA7 HSHCS application type of the HSS9820
type of the UPCC.
MNRSU: SingleSDB FE application type with data
collectively deployed. It consists of the DRU and DSU
of multiple FEs.
MNGBA: application type with the BSF and AP
functions of the UIM collectively deployed. It consists of
the DRU and DSU of the BSF.
UPBA2 ETIA0 GUHGU: HLR universal unit. This unit contains all the
functions of the HLR FE and HLR BE. That is, the
UPBA6 ETIA0

Board Board
Type Type
GUHGU is used for signaling access and processing,

and data routing and storage.
UPBA2 ETIA2 GUHGU: GUHGU: HLR universal unit. This unit

contains all the functions of the HLR FE and HLR BE.
UPBA6 ETIA2 That is, the GUHGU is used for signaling access and
processing, and data routing and storage.
MNUFE: integrated FE application type of SingleSDB.
EER(EER) MSPB0 RPUA0 RPU: IP routing and L2 convergence. The RPU can
route data from the WANports to the protocol
processing modules of the service MEs and converge
the outbound messages addressed to external devices
to the EER and then send out, which achieves single-
site access.
RCC(RCC) UPBA0 ETIA0 RCCU: The RCCU receives call event requests from
the regional network, implements user-based, domain-
UPBA0 USIA1 based, and service-based differentiated services based
on the combination of multiple conditions, including the
calling and called parties, location area, and call type in
the call event requests.
CG(CG) UPBA1 USIA1 CGU: Charging gateway. It provides the office charging
function in the PS domain. Deployed with the CG
UPBA1 USI1 modules, the board can receive CDRs, combine and
sort CDRs, convert the CDR format, distribute CDRs to
UPBA1 USI2 the billing center, back up the CDRs to a third-party
server, and provide a Web page for CDR browsing.
UPBA2 USIA1
UPBA2 USI1
UPBA6 USIA1
UPBA6 USI1

Board Board
Type Type
UPBA5 USIA1
UPBA5 USI1
UPBA5 USI2
ENS(ENS) UPBA0 USI1 ENSFU: ENS FE unit. This unit only contains the
function of ENS. That is, the ENSFU is only used for
UPBA0 USI2 signaling access and processing.
UPBA0 USIA1
UPBA2 USI1 ENSFU: ENS FE unit. This unit only contains the
function of ENS. That is, the ENSFU is only used for
UPBA2 USI2 signaling access and processing.
ENSIU: ENS integrative unit. This unit contains the
UPBA2 USIA1 functions of the ENS FE and USCDB(DRU, DSU,
DSG, DPU). That is, the ENSIU is used for signaling
UPBA6 USI1 access and processing, and data routing and storage.
UPBA6 USI2
UPBA6 USIA1
UPBA2 USIB0 ENSIU: ENS integrative unit. This unit contains the
functions of the ENS FE and USCDB(DRU, DSU,
UPBA6 USIB0 DSG, DPU). That is, the ENSIU is used for signaling
access and processing, and data routing and storage.
UIM(UIM) UPBA0 ETIA0 UIMU: UIM signaling processing unit. This unit is used
to set up connections with other access devices and
UPBA0 ETIA2 implements signaling service processing to complete
authorization, authentication, and accounting. The
UPB1 ETIA0 UIMU consists of two functional modules, namely, the
signaling access unit and the service processing unit.
UPB1 ETIA2 UAMU: service processing unit of the UIM. The UAMU
boards are used to perform the authentication.
UPB1 USIA1 UMHU: service processing unit. The UMHU boards of
the UIM are used to process signaling sent from the
HLR.
UMSU: service processing unit of the UIM. The UMSU
boards are used to perform the authentication and
provides interface for short message processing.

Board Board
Type Type
UPB1 USIA7 UAMU: service processing unit of the UIM. The UAMU
UMHU: service processing unit. The UMHU boards of
HLR.
UPBA2 ETIA0 UIMU: UIM signaling processing unit. This unit is used
UPBA2 ETIA2 implements signaling service processing to complete
UPB0 ETIA0 UIMU consists of two functional modules, namely, the
UPB0 ETIA2 UAMU: service processing unit of the UIM. The UAMU
UPBA6 ETIA0 UMHU: service processing unit. The UMHU boards of
UPBA6 ETIA2 HLR.
UTAU: The UIM and USCDB can be deployed together
on this board.
UPB0 USIA1 UIMU: UIM signaling processing unit. This unit is used
implements signaling service processing to complete
UIMU consists of two functional modules, namely, the
UAMU: service processing unit of the UIM. The UAMU
HLR.
UPSU: Portal processing unit of the UIM.
on this board.

Board Board
Type Type
UCSU: UIM NE SSO processing unit, this unit performs

single sign-on authentication feature.
UPB0 USIA7 UAMU: service processing unit of the UIM. The UAMU
HLR.
on this board.
UPBA2 USI1 UPSU: Portal processing unit of the UIM.

UPB0 USI1 on this board.
UPBA6 USI1 single sign-on authentication feature.
UPBA0 USIA1 UIMU: UIM signaling processing unit. This unit is used
UPBA0 USIB0 implements signaling service processing to complete
UIMU consists of two functional modules, namely, the
UAMU: service processing unit of the UIM. The UAMU
HLR.
UBSF: service processing unit. The UBSF boards of
the UIM are used to perform the authentication during
universal authentication.
UAPU: service processing unit. The UAPU boards of
the UIM are used to perform the authentication agent
and forwarding during universal authentication.

Board Board
Type Type
UPBA0 USIA7 UAMU: service processing unit of the UIM. The UAMU
HLR.
UPBA2 USIA1 UIMU: UIM signaling processing unit. This unit is used
UPBA2 USIB0 implements signaling service processing to complete
UPBA6 USIA1 UIMU consists of two functional modules, namely, the
UPBA6 USIB0 UAMU: service processing unit of the UIM. The UAMU
HLR.
on this board.
UBAU3: board on which the USCDB and the UIM
serving as the UBSF and UAPU are deployed. It is
used for Utinterface authorization.

Board Board
Type Type
UPBA2 USIA7 UAMU: service processing unit of the UIM. The UAMU
UPBA6 USIA7 UMHU: service processing unit. The UMHU boards of
HLR.
on this board.
UBAU3: board on which the USCDB and the UIM
serving as the UBSF and UAPU are deployed. It is
used for Ut interface authorization.
UPCC(UPCC) GPU0 USI0 UPRPU: resource process unit of UPCC. This type of
UPB0 USI6 policies, charging rules, and routing data of the UPCC.
The boards of this application type must be deployed in
UPB0 USI1 conjunction with the boards of other application types.
UPIRU: integrative resource unit of UPCC. This type of
application controls the resources and policies of the
UPCC.
UPPDU: policy management unit of UPCC. This type
of application provides policies and the UPCC WebUI.
conjunction with the boards of other application types.
UPBA0 USI1 UPRPU: resource process unit of UPCC. This type of

policies, charging rules, and routing data of the UPCC.
UPCC.

Board Board
Type Type
UPBA0 USIA1 UPRPU: resource process unit of UPCC. This type of

policies, charging rules, and routing data of the UPCC.
UPCC.
UPCSPU: cable service processing unit of the UPCC.
This type of application provides the service
processing function of the UPCC in a cable network.
conjunction with the boards whose application type is
UPCPPU.
UPCPPU: cable protocol processing unit of the UPCC.
This type of application provides the protocol
processing function of the UPCC in a cable network.
conjunction with the boards whose application type is
UPCSPU.
UPBA0 USIB0 UPIRU: integrative resource unit of UPCC. This type of

UPBA2 USIB0 UPCC.
UPBA2 USI2 UPPDU: policy management unit of UPCC. This type

UPBA2 USIA1 The boards of this application type must be deployed in
UPBA6 USI2
UPBA6 USIA1 UPPEU: policy enabler unit of the UPCC. The UPPEU
provides the open api for policy control capability. It
must be deployed with boards of other application
types.
UPPDU: policy management unit of UPCC. This type
UPBA6 USIB0 UPIRU: integrative resource unit of UPCC. This type of

UPCC.
AGCF(AGCF) UPBA0 USIA1


Board Board
Type Type
UPBA0 USIB0 UACGU: General unit of the AGCF. This unit contains
the processes ACU, BSG, CDB, and IFM.
TMS(TMS) UPBA6 USIA1 TMTMS: This is the TMS9950 core network element
(NE) that processes service logic during device
management.
TMDBS: This is the database server that stores system
data.
TMLBS: This is the TMS9950 load balance server that
forwards the northbound requests to the TMTMS.
TMCTDS: The Integrated unit that Composed by the
TMTMS and TMDBS processes service logic and
stores system data.
RCS(RCS9100) UPBA6 USI2 RCSAS: RCS application server. This server

implements the functions of the RCSIM, RCSPS,
RCSXM, and RCSDB, and provides all RCS services,
such as instant messaging (IM) service, Presence
service, group management service, and database
storage. This server is deployed on an independent
board.
RCSDB: RCS database server. This server stores
related service data. It shares a board with other
application servers.
UPBA6 USIA1 RCSIM: RCS IM server. This server processes IM

service logic and creates, maintains and ends IM
sessions. It shares a board with other application
servers.
RCSPS: RCS presence server. This server
process Presenceservice logic and provides Presence
service subscription, launching and management. It
shares a board with other application servers.
RCSXM: RCS XML document management server.
This server processes the logic of group and user list
management, and stores and manages authorization
policy and subscription policy for subscribers. This
server shares a board with other application servers.
RCSDS: RCS directory server. This server processes
the service logic of the network directory, uploads,
updates and synchronizes directories, and responds to
subscriber requests. This server shares a board with
other application servers.
RCPGM: RCS general management unit. This unit
consists of the RCSIM, RCSPS and RCSXM units and

Board Board
Type Type
provides the IM, Presence, and group management

services. It is required when the database on the
RCSAS is independently deployed. This server shares
a board with other application servers.
UPBA6 USIA7 RCSAS: RCS application server. This server

implements the functions of the RCSIM, RCSPS,
RCSXM, and RCSDB, and provides all RCS services,
such as instant messaging (IM) service, Presence
service, group management service, and database
storage. This server is deployed on an independent
board.
RCSIM: RCS IM server. This server processes IM
service logic and creates, maintains and ends IM
sessions. It shares a board with other application
servers.
RCSPS: RCS presence server. This server process
Presence service logic and provides Presence service
subscription, launching and management. It shares a
board with other application servers.
RCSXM: RCS XML document management server.
This server processes the logic of group and user list
management, and stores and manages authorization
policy and subscription policy for subscribers. This
server shares a board with other application servers.
RCSDS: RCS directory server. This server processes
the service logic of the network directory, uploads,
updates and synchronizes directories, and responds to
subscriber requests. This server shares a board with
other application servers.
RCPGM: RCS general management unit. This unit
consists of the RCSIM, RCSPS and RCSXM units and
provides the IM, Presence, and group management
services. It is required when the database on the
RCSAS is independently deployed. This server shares
a board with other application servers.
SPS(SPS) UPBA0 USIA1 SDAU: basic signaling route processing unit of the
SPS. It contains IFM, DAU, BSG, SSU, DCU, and DSG
UPBA0 USIA7 processes and is the basic configuration for the SPS to
process Diameter and STP signaling.
SSRU: SIP signaling processing unit of the SPS. It
contains IFM, BSG, SRU, and DCU processes and is
the basic configuration for the SPS to process SIP
signaling.

Board Board
Type Type
UPBA0 ETIA0 SDAU: basic signaling route processing unit of the

UPBA0 ETIA2 processes and is the basic configuration for the SPS to
UPBA0 USIB0 SDAU: basic signaling route processing unit of the

processes and is the basic configuration for the SPS to
SDPU: basic IP packets dispatching unit of the SPS. It
contains the IFM process used to receive and send the
IP packets. It is configured when the SPS converges
the IP signaling.
SSRU: SIP signaling processing unit of the SPS. It
contains IFM, BSG, SRU, and DCU processes and is
the basic configuration for the SPS to process SIP
signaling.
UPBA6 USIA1 SASU: signaling analysis support unit. It contains AP,

SI, DP, and IFM processes and is the basic
configuration for the SPS to analyze signaling.
SANEX(SANEX) UPBA6 USIA1 SANEX: It is a signaling analysis unit that provides the
signaling monitoring function.
UPB0 USI1
GTSOFTX(GTSOFTX) UPBA0 ETIA0 GTSX: Serves as the GSM-R and GSM-T mobile
switching center that integrates the functions of the
UPBA0 ETIA2 MSC, VLR, SSP, GCR, and IWF. By working with other
NEs, provides basic telecommunications services,
UPBA0 USIA1 supplementary services, intelligent services, and value-
added services. In addition, it supports various GSM-R
UPBA0 SSIA0 dispatching and digital trunking services.
UPBA0 SSIA2
UPBA5 ETIA0 EUMG: Serves as a MGW in the GSM-R and GSM-

Trunking (GSM-T) network. This unit implements the
UPBA5 ETIA2 bearer interworking on the service plane.
EHLR: Serves as the GSM-R and GSM-T home
UPBA5 USIA1 location register. This unit is not only used for setup of
connections with other mobile network entities and
processing of signaling services, such as MAP
operations of call processing and location registration,
but also used for data storage.

Board Board
Type Type
ESCP: Serves as a Service Control Point in the GSM-

R and GSM-Trunking (GSM-T) network. This unit
provides intelligent network (IN) services by controlling
the service switching point(SSP)/intelligent
peripheral(IP).
UPBA6 ETIA0 EUMG: Serves as a MGW in the GSM-R and GSM-

Trunking (GSM-T) network. This unit implements the
UPBA6 ETIA2 bearer interworking on the service plane.
EHLR: Serves as the GSM-R and GSM-T home
UPBA6 USIA1 location register. This unit is not only used for setup of
connections with other mobile network entities and
processing of signaling services, such as MAP
operations of call processing and location registration,
but also used for data storage.
ESCP: Serves as a Service Control Point in the GSM-
R and GSM-Trunking (GSM-T) network. This unit
provides intelligent network (IN) services by controlling
the service switching point(SSP)/intelligent
peripheral(IP).
EGTSX: Serves as the GSM-R and GSM-T mobile
switching center that integrates the functions of the
MSC, VLR, SSP, GCR, and IWF. By working with other
NEs, provides basic telecommunications services,
supplementary services, intelligent services, and value-
added services. In addition, it supports various GSM-R
dispatching and digital trunking services.
eCNS(eCNS) ESUA0 QXIA0 ISU: integrated service processing unit. Many service
processes such as MME, S/P GW, HSS and PTT can
be integrated in the ISU.
HSS9860(HSS9860) UPB0 ETIA0 FEU: HSS signaling processing unit. This unit is used
to connect to other mobile network entities and
UPB0 ETIA2 processing of signaling services, such as MAP or
Diameter operations of call processing and location
UPB0 SSIA0 registration. The FEU contains a signaling access unit
and a service processing unit.
UPB0 SSIA1
UPB0 USIA1
UPB0 USI1
UPBA0 ETIA0

Board Board
Type Type
UPBA0 ETIA2
UPBA0 SSIA0
UPBA0 SSIA1
UPBA0 USIA1
UPBA0 USI1
UPBA0 USIB0
UPBA2 ETIA0
UPBA2 ETIA2
UPBA2 SSIA0
UPBA2 SSIA1
UPBA2 USIA1
UPBA2 USI1
UPBA2 USIB0
UPBA6 ETIA0
UPBA6 ETIA2
UPBA6 SSIA0
UPBA6 SSIA1
UPBA6 USIA1
UPBA6 USI1
UPBA6 USIB0
UPB1 ETIA0
UPB1 ETIA2

Board Board
Type Type
UPB1 USIA1
ATS_MRFC(ATS_MRFC) UPBA0 USI1 ASSCU: session control unit. The SCU is the media
resource control process of the ATS_MRFC and is
UPBA0 USIA1 responsible for controlling and processing media
resources.
UPBA0 USIA7 ASCDB: central database. The CDB is the central
database process of the ATS_MRFC and is
UPBA0 USIB0 responsible for maintaining global system data and
distributed subscriber data.
UPB0 USI1 ASBSU: broadband signaling unit. The BSU is the
signaling process of the ATS_MRFC. It terminates
UPB0 USI6 TCP/SCTP connections, encodes/decodes
COPS/Diameter signaling, converts the signaling into
GPU0 USI0 internal messages, and forwards the messages to the
SCU process.
ASDPU: dispatching unit. The DPU is the dispatching
process of the ATS_MRFC. Functioning as an external
interface of the ATS_MRFC, the DPU process receives
IP packets from the external system, forwards the
packets to corresponding BSU processes, and
forwards outbound IP packets to the external system.
ASDSU: dispatch and signaling unit. The DSU
provides functions of both the DPU and BSU modules.
A back board must be configured for the DSU.
ASISU: integrated session unit
(BSU+SCU+CDB+DPU). The ISU provides all
functions of the ATS_MRFC. A back board must be
configured for the ISU.
UPA-DSP(UPA-DSP) UPBA0 ETIA0 UPFEU: Service processing unit of the DSP. This unit
connects to data source devices, collects data from
UPBA0 ETIA2 them, and analyzes the collected data. In addition, it
provides open interfaces to third-party devices and
UPBA0 SSIA0 shares the collected data with them.
UPBA0 SSIA1
UPBA0 USIA1
UPBA5 ETIA0
UPBA5 ETIA2
UPBA5 SSIA0

Board Board
Type Type
UPBA5 SSIA1
UPBA5 USIA1
UPBA6 ETIA0
UPBA6 ETIA2
UPBA6 SSIA0
UPBA6 SSIA1
UPBA6 USIA1
UIC(UIC) UPBA3 - NCU: network control unit, which processes signaling

and services.
MSPB0 PFIA0 NPU: network packet forward unit, which transfers data
and provides interfaces.
ESUA0 PFIA0 SCU: service control unit, which is an enhanced

service processing board. It combines the functions of
ESUA0 QXIA0 the NCU and the NPU boards, and enhances the
service processing capability and product integration.
UFCB0 PFIA0
MNB_UAC(MNB_UAC) UPBA6 USIA7 UACSU: SoftX3000 assembled elements UIO. A board

of this application type can house multiple network
entities, such as SoftX3000, iGWB, and CGP.
GTSERVER(GTSERVER) UPBA5 USIA1 AC: Responds to and processes AC messages, saves

AC data, and allows users to query AC call information
for further analysis.
ISS: Integrated Service Server. Functions as an
interface adaptation device on the GSM-R network,
mainly provides external MLP interface adaptation for
the MSC server, and queries mobile subscriber
locations when the controller terminal system (CTS)
interacts with the MSC server and functional number
information.
ACISS: Collectively deployed AC and ISS. Used on the
GSM-R networks to meet the requirements on both AC
and ISS.
GMS: Group management server. Manages resources,
network elements, virtual private networks, enterprises,

Board Board
Type Type
enterprise users, dispatching areas, groups, VGCS

users, open channels, subscriber numbers, and
operators.
UPORTAL(UPORTAL2800) UPBA6 USIA7 UPSCB: uportal service control base. It is a functional

module of the UPortal2800. Serving as a unified UC
UPBA6 USIB0 service, the UPortal2800 provides enterprise
administrator portal, personal portal, enterprise
address book and a unified access control center.
UPXPU: uportal expand process unit, a functional
module of the UPortal2800, improving UC service
provisioning performance of the UPSCB when the
UPortal2800 is deployed in distributed mode.
Table 2 describes application types of boards that do not support the IMU.
Table 2 Application types of boards that do not support the IMU
ME type Application type
MEDIAX(MEDIAX) MXDCU
UGC(UGC) UGXPT
IPCTRX(IPCTRX) ETOSA
ETXMA
ETOSB
ETXMB
ENUM_SERVER(ENUM_SERVER) ENSRV
CHR(CHR) CHR
SGSN-USN(SGSN-USN) CGW
DNS
TMS(TMS) TMTMS
TMDBS
TMLBS
TMCTDS
Notes
None.
Add Board (ADD BRD)
Remove Board (RMV BRD)
Modify Board (MOD BRD)
List Board (LST BRD)
Display Board (DSP BRD)
Reset Board (RST BRD)
Soft Reset Board (SRST BRD)
Swap Board (SWP BRD)
Power On Board (PON BRD)
Power Off Board (POF BRD)
Format Board (FMT BRD)
List Board Specification (LST BRDSPEC)
Reset Communication Plane of Switch Board (RST SWUPLANE)
Display Port (DSP PORT)
DSP PORT is used to query the operating status of a port.

Note
This command is used to query the operating status of the ports of back board (including Electrical
ethernet, Fiber ethernet, 10 gigabit fiber ethernet, FC port and ATM), front board and switch board.
This command cannot be used to query the running status of the Fabric ports on the MPF0 or MPF1
boards. To query the running status of the Fabric ports on these boards, check information about
alarms generated by corresponding MEs.
This command cannot be used to query the operating status of the E1/T1 ports and STM ports of a
narrowband back board. To query the operating status of the E1/T1 ports and STM ports of a
narrowband back board, run DSP ET1PORT and DSP STMPORT.
List Port (LST PORT)
LST PORT is used to query the configuration information of a port.

To query the brief information about all the ports, do not specify any parameter.
To query the detailed information about ports on a specific board, specify Subrack number and Slot
number.
Note
This command is used to query the configuration information of the ports (including Electrical
ethernet, Fiber ethernet, 10 gigabit fiber ethernet, and ATM) of only a back board.
This command cannot be used to query the configuration information of the E1/T1 ports
and STM ports of a narrowband back board. To query the configuration information of the E1/T1
ports and STM ports of a narrowband back board, run LST ET1PORT and LST STMPORT.
You cannot run this command on the CGP to query the configuration information about the ports on
the boards of the EER. To query the configuration information about the ports on the boards of the
EER, run corresponding MML commands on the EER.
This command is not applicable to ports on the switch boards and the boards of the NIU0 type.
When Port type in the command output is Fiber ethernet or 10 gigabit fiber ethernet, Expect
work mode, OAM state, OAM mode, and OAM threshold are invalid and displayed as NULL.
DSP ELABEL is used to query the electronic label of the equipment. After this command is executed
successfully, the electronic label is displayed in the format of an MML message, and the obtained
electronic label is saved on local as an image file. The image file is saved
to /opt/HUAWEI/cgp/workshop/omu/share/devicefile/ of the OMU board. You can download the image
file using the File Transfer Service by choosing Maintenance > File Transfer Service on
the Huawei Operation & Maintenance System, and selecting Device file from the drop down list
of Remote Directory on the right pane.
The object to be queried may be one of the following types:
Entire rack
Entire subrack
Board
SDM board
Fan tray
Power entry module
Power distribution box
Note
If the electronic label information is not available, the possible cause may be the following:
The specified slot is not configured with a front or rear board.
No board exists in the subrack, though a front or rear board is configured.
This command does not apply to the optical modules connected to FC ports.
LST ELABEL is used to query the local electronic label information. The objects can be queried are as
follows:
Entire rack
Entire subrack
Board
SDM board
Fan tray
Power entry module
Note
Get E-Label Information (GET ELABEL)

Function
GET ELABEL is used to obtain the electronic label information about a device and save the information
to a file in the specified directory on the specified server. During the retrieval process, the system displays
messages to report the progress. During hardware information maintenance and management, you can
use this command to query the electronic label information about each device. The object to be queried
may be one of the following types:
Entire rack
Entire subrack
Board
SDM board
Fan tray
Power entry module
Note
If obtaining the electronic label information about a device fails, the possible causes are as follows:
The transfer of the electronic label information fails, and the possible causes are as follows:
Incorrect username
Incorrect password
Incorrect server IP address
Incorrect protocol
Incorrect server port
Server unavailable
Reached the maximum connections of the server
Network unavailable
No permission to operate the destination directory (uploading)
Insufficient disk space
Invalid destination directory (the file name is not specified or the root directory does not exist)
Failed to overwrite the original file or a directory with the same name exists
No response from the server (transfer times out or the server does not respond)
If the electronic label information is not available, the possible cause may be the following:
The specified slot is not configured with a front or rear board.
No board exists in the subrack, though a front or rear board is configured.
The current version does not support the upload of electronic label information to Windows OS.
Display System Resource (DSP SYSRES)
Function
DSP SYSRES is used to query the usage of system resources, such as the disk, and CPU of the board,
the memory, message packets, queues, timers, and file handles of the module, which reflects the
performance of the system. You can run this command to query the usage of different resources of a
board or a specific module.
Note
Running the DSP SYSRES command consumes CPU resources. The amount of consumed CPU
resources is proportional to the number of system resources you attempt to query. Therefore, to
avoid consuming a large amount of CPU resources, you are advised to specify Subrack
numberand Slot number to restrict the query scope. Generally, do not specify
only Board/Module for running this command.
In addition, partial board memory resources are used by the file system, and the information about
these resources is displayed in the query result of board disk resources.
Clean Up OMU Disk (CLR OMUDISK)
Function
CLR OMUDISK is used to clean up the disk of an active OMU board.

Note
This command can be used to clean up the files in /opt.

This command cannot be used if either the following conditions is met:
The disk usage is less than or equal to the value of Usage threshold level 1.
The total disk space is greater than or equal to 128 GB and the available disk space is greater
than 20 GB.
To query the thresholds of the disk usage, run LST ALMTHD.
Power Distribution Box
Terms Explanation
The PDB connects the power distribution cabinet to subracks, assigns power based on output
requirements, and detects the status of the input voltage and output voltage. Once the PDB detects that
the voltage is out of the specified range, the alarm buzzer sounds.
Function Description
The commands of this node are used to manage the power distribution box (PDB). You can use the
commands to: Add, remove, modify and query the PDB.
In this section, the service processing cabinet is considered as an example. Introduction of the PDB
cascading mode:
Local: The PDB and the SDM board mapping the parameter Subrack number reside in the same
rack. The blue lines of the service processing cabinet indicate the connection between the J1 and J2
serial ports of the PDB and the COM2 serial port of the SDM board of the subrack (located at the
bottom of the cabinet, with the smallest subrack number), as shown in Figure 1.
Another: The PDB and the SDM board mapping the parameter Subrack number reside in different
racks. There are two connection types in actual applications.
Connection of blue cables in Figure 1: Connect the J1 and J2 serial ports of the PDB in network
cabinet 1 and the COM2 serial ports of the SDM board in the free subrack of the service
processing cabinet.
Connection of red cable in Figure 2: When the service processing cabinet does not have free
subracks, connect the J7 serial port of the PDB in the service processing cabinet and the J7
serial port of the PDB in network cabinet 1 by using a PDB cascading monitoring cable.
Figure 1 PDB monitoring cables connection of a network cabinet
Figure 2 Connection of cascading PDB monitoring cable for a network cabinet
Notes
None.
Add Power Distribution Box (ADD PDU)
Remove Power Distribution Box (RMV PDU)
Modify Power Distribution Box (MOD PDU)
List Power Distribution Box (LST PDU)
Display Power Distribution Box (DSP PDU)
Reset Power Distribution Box (RST PDU)
Set PDB Config Data (SET PDUCFGDATA)
Display PDB Config Data (DSP PDUCFGDATA)
Set PDB Alarm Mask (SET PDUALMMSK)
Display PDB Alarm Mask (DSP PDUALMMSK)
Set PDB Buzzer Switch (SET PDUBZSW)
Display PDB Buzzer Switch (DSP PDUBZSW)
Set PDB External Sensor Name (SET PDUSNM)
List PDB External Sensor Name (LST PDUSNM)
List Version Information (LST VERINFO)
Function
LST VERINFO is used to query the version configuration information imported to the OMU between the
service MEs and the modules of the service MEs.
Run this command when you want to obtain the mapping information about the ME versions that have
been configured on the OMU.
Note
To query the version configuration information between all the service MEs and the modules of the
service MEs, do not specify the ME type parameter.
To query the version configuration information between the service MEs and the modules of the
service MEs managed by the CGP of all versions or the current version, specify the Version
typeparameter. If Version type is left unspecified or is set to Current version, the system queries
the version mapping information based on the current CGP version. If a service ME version maps to
multiple CGP versions, the ME information sometimes cannot be displayed in the command output.
To solve the problem, set Version type to All version.
Display Version (DSP VER)
Function
DSP VER is used to query the version of a module of the host. If no parameter is set, the versions of all
the modules of all MEs are displayed; if certain parameters are set, the versions of the specified modules
of the specified MEs are displayed.
Note
The parameters ME ID and Module number are optional. If you specify a value for Module
number, you must also specify a value for ME ID.
The result is displayed only when the modules are operating properly. If the modules are not
operating properly, the NULL information is displayed.
By default, the version configuration information is imported automatically during the execution of
the LOD PKG command. If the version mapping between an ME and the modules of the ME is a legal
one in the system, Version consistent is displayed; otherwise, Version inconsistent is displayed.
Display Board Software (DSP BRDSFT)
Function
DSP BRDSFT is used to query the information about the software configuration of a board or the
software installed on a board.
Note
The target board must be a configured server board.

When Method is set to All, the information about the server boards that are configured but not
present will not be displayed in the command output.
For boards whose application type is listed in Application types of boards that do not support the
IMU, Installed software version is NULL and Installation check result is Consistent in the
command output because there is no IMU module running on the boards.
List the Installation Task Number (LST INSTNUM)
Function
LST INSTNUM is used to query the number of server boards that can be installed simultaneously through
the OMU board.
Display Communication Quality Information (DSP COMMQLTY)
Function
DSP COMMQLTY is used to query the communication quality of a board.

Figure 1 shows the relationship between the Base plane and the Fabric plane associated with this
command.
NOTE:
Basic subrack (subrack 0) and extensive subrack are taken as an example. The communication
between the two subracks is in the Internal Switch Board mode. For details about inter-subrack
cascading, see Cascading Mode.
SWU is the front switching board and SWI is the back board of the SWU.
The Fabric ports on the front SDPU board are not used. The SDPU board communicates with other
boards through the Card1/SFP1 and Card3/SFP0 ports on the back board.
The Base plane cannot communicate with the Fabric plane.
Figure 1 Relationship between the Base plane and the Fabric plane
Note
Display Communication Link State (DSP COMM)
Function
DSP COMM is used to query the status of the communication link between the source module and the
peer module or OMU. This command is applicable to routine maintenance of communication links.
Note
When you run this command, ensure that the source module is running normally. You can run DSP
MODULE to get the existing modules with Active/Standby state set
to ACTIVE(Active) or STANDBY(Standby).
Display System IP Information (DSP IPINFO)
Function
DSP IPINFO is used to query system IP information, including IP address information, routing rule
information, route information, and ARP information.
Note
If no information option (IPITERM) is selected, the output contains information about all options. The
maximum number of items displayed for an option is as follows:
IP (IP address): 32
RULE (routing rule): 32
ROUTE (route information): 128
ARP (ARP information): 64
If the displayed number of items of these options reaches the maximum, you can choose this option
to query all its data.
If a particular information option is selected, the output contains all information only about that
option. The maximum number of items displayed for an option is as follows:
IP (IP address): 256
RULE (routing rule): 256
ROUTE (route information): 256
ARP (ARP information): 512
Switch boards (in slots 6 and 7) do not support IP information query.
PING (PING)
Function
PING is used to check the network reachability, that is, the connection of the network.
Note
This command applies only to the UPB board housing the IMU module and external network port (The
boards whose application types are listed in Application types of boards that do not support the IMU are
not supported).
TRACERT (TRACERT)
Function
TRACERT is used to check the routed path, that is, the connection route between the specific source IP
address and the destination IP address.
Note
This command applies only to the UPB board housing the IMU module and external network port (The
boards whose application types are listed in Application types of boards that do not support the IMU are
not supported).
Display IP Statistics (DSP IPSTAT)
Function
DSP IPSTAT is used to query the statistics on service IP data packets sent and received by a specific
ME.
The data packets include the IP, TCP, UDP, SCTP, ESP, and other types of packets.
Display NTP Server (DSP NTPSVR)
Function
DSP NTPSVR is used to query the operating status of an NTP server.
List NTP Server (LST NTPSVR)
Function
LST NTPSVR is used to query the configuration information about the NTP server.
Display Time (DSP TIME)
Output Item Description
Current time This parameter indicates the current time of the OMU.
of system The following values are used as examples:
Current time of system = 2009-12-30 00:31:07+09:00 DST: The OMU time is

September, 30th, 2009 and DST is observed. The time zone is GMT+8 if DST
offset value is 60 minutes.
Current time of system = 2009-12-30 00:31:07+00:00: The OMU time is

September, 30th, 2009 and DST is not observed.
List Time Zone and Daylight Saving Time (LST
TZ)
Display OMU (DSP OMU)
Function
DSP OMU is used to query the status and resource information about the OMU.
Note
In HA mode, if the standby OMU state is Unknown or Breakdown, the

displayed Subrack number, Slot number, and Start run time of the standby OMU are
invalid.
It takes a long time to query the status of all resources. Therefore, the status of the
resources displayed is that saved during resource monitoring, which may be different
from the actual resource status.
Swap OMU (SWP OMU)
Function
NOTICE:
Running of this command will cause interruption of operation & maintenance (O&M) for 30
seconds. Therefore, exercise caution when deciding to run this command.
SWP OMU is used to swap the OMUs in high availability (HA) mode
During parts replacement, upgrade, or patching, you can use this command to swap
the OMUprocesses. After the active OMU switches to the standby state, you can replace the
board or other parts on the board without interrupting the services.
Note
During the swap, the OMU services are unavailable. In normal cases, the swap process
takes about 30 seconds.
The SWP OMU command is applicable only to the HA system. A non-HA system does
not support swap. You can run DSP OMU to check whether the OMU works in HA
mode.
After running SWP OMU, you can run DSP OMU to query the
current active/standby state of the OMUs to determine whether the swap is successful.
Reset OMU (RST OMU)
Function
NOTICE:
Running of this command may cause temporary service interruption in the O&M system.
Therefore, exercise caution when deciding to run this command.
RST OMU is used to reset OMU modules.

You can use this command to perform the following operations:
Enable the modification of the system configuration to take effect.
Restore the error information that cannot be restored through switchovers, such as
records of abnormal resources.
Reset an OMU module, which minimizes the impact on the whole OMU.
Note
All modules of the OMU will be reset if the OMU module name is not specified.
Services provided by the OMU cannot be used during the reset of all OMU modules.
Therefore, the active services will be interrupted. Run this command carefully. In normal
conditions, the reset takes about 1 minute.
After all modules of the OMU reset, the error records of the OMU resources are deleted.
In High Availability (HA) mode, the active/standby status is the same as that before the
reset of all modules of the OMU. If modules of the OMU are abnormal during the reset,
an active/standby switchover may be triggered. In this case, the active/standby status is
different from that before the reset, and the OMU reset may take a long time.
In HA mode, the active and standby OMUs will be reset if all modules of the OMU are
reset. If communication between the active and the standby OMUs fails, the standby
OMU cannot be reset.
When an OMU module is reset, this command execution only takes effect on the active
OMU modules.
When an OMU module is reset, other modules depending on it are also reset. Currently,
when the SECURITY module is reset, the MMLSERVER module is also reset.
Clear Resource Activation Failure Flag (CLR

FAILFLG)
Function
CLR FAILFLG is used to clear the flag of a failure in activating resources on the OMU when
the OMU works in high availability (HA) mode.
After ALM-8600 Abnormal OMU Resources is cleared, you can use this command to clear
the flag of the failure in activating resources on the OMU according to the alarm help.
Note
Before running CLR FAILFLG, view ALM-8600 Abnormal OMU Resources by using the
alarm browser of the client and clear the alarm according to the alarm help. After the
alarm is cleared, run this command.
If a certain resource on the active OMU is abnormal, an active/standby switchover may

occur immediately after CLR FAILFLG is executed.
CLR FAILFLG applies only when the OMU works in HA mode. You can run DSP OMU to
check whether the OMU works in HA mode.
List Sync Status (LST SYNC)
Function
LST SYNC is used to query the synchronization status of the active and standby OMUs that
work in HA mode. After the command is executed successfully, the system displays the
synchronization subject (files or database) and the synchronization progress, the files that
fail to be backed up, and the connection status of the database data synchronization
resource, namely, DBHA.
The command output contains the following information:
Active/standby OMU synchronization progress
Database DBHA status
Logs never rebuild
Logs failed to rebuild
Active/standby OMU synchronization progress and Database DBHA status are displayed
unconditionally. Logs never rebuild and Logs failed to rebuild are displayed based on the
actual conditions of the current environment.
Run Failed Sync Logs (RUN FAILS)
Function
RUN FAILS is used to resynchronize the files that are not synchronized or fail to be
synchronized with the standby OMU based on the error logs.
You can use this command to resynchronize files that fail to be synchronized.
Note
Before running this command, run LST SYNC to query the names of files that fail to be
synchronized. If all the files are synchronized successfully, you do not need to run this
command.
Reset Sync (RST SYNC)
Function
RST SYNC is used to re-initialize the synchronization data. After the command is executed
successfully, all the data on the active OMU is synchronized with the standby OMU.
You can use this command to perform an immediate data synchronization between the
active and standby OMUs.
Note
After the command is executed successfully, the files and database in the installation
directory of the active OMU are synchronized with the standby OMU. In addition, the
error logs on the standby OMU are deleted.
During the initialization of the synchronization data, the system compares and
synchronizes the data between the active and the standby OMUs. Therefore, a large
number of system resources are occupied. You are advised to run this command when
the traffic is light.
List Alarm Configuration (LST ALMCFG)
Function
LST ALMCFG is used to query the alarm configuration.
List Event Logs (LST EVTLOG)
Function
LST EVTLOG is used to query the logs on an event.
To query the brief information about all events, do not specify any parameter.
To query the detailed information about specific events, specify Start event ID and End
event ID, or other parameter combinations.
OMU HA
Term Explanation
The OMU provides multiple operation modes to adapt to different scenarios.

Single mode: Only one OMU provides services. There is no redundant device. The
reliability is low.
Non-disk-array HA mode: Two OMUs are used, one of which serves as a redundant
OMU. The two OMUs use a floating IP address for external communication. The
reliability is high. The databases and log files on the active and standby OMUs are used
to ensure data redundancy. Therefore, the cost of this OMU HA mode is low.
You can determine the operation mode when installing the OMU. The HA mode provides the
high availability of the OMU. Figure 1shows the typical networking where the OMUs adopt
the HA mode. The active and standby OMUs communicate with external entities such as the
LMT and the OSS through the floating IP address configured for the BACK port. The active
and standby OMUs are connected to the platform process and the service ME process
through the floating IP address configured for the BASE port.
Figure 1 Typical networking where the OMUs adopt the HA mode (double-LAN switch mode,
which is used currently).
The system provides query and maintenance commands that are used to manage and
maintain OMUs. Some commands are applicable only to the HA mode. For details, refer to
the command description.

LMT Processes

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

LMT Processes

Uploaded by

Copyright:

Available Formats

LMT Processes

Table 1 LMT Processes Function description

Function Name Function Description

Function Name Function Description

Function Name Function Description

LMT Software Directories

Table 1 File paths of the LMT

D:\HW iLMT\uninstall The configuration files of the LMT for uninstalling

D:\HW iLMT\omu\workspace1\adaptor The configuration files and supporting files related to

D:\HW The executable files and supporting files of the log

D:\HW The executable files and supporting files of the

D:\HW The executable files and supporting files of the tracing

D:\HW The startup file of the alarm box tool.

D:\HW iLMT\omu\workspace1\client\lmt_client.exe The startup file of the LMT.

D:\HW iLMT\omu\workspace1\client\putty.exe The startup file of the PuTTY.

D:\HW iLMT\omu\workspace1\client\infogather\infogather.exe The startup file of the log collection

D:\HW The startup file of the PTMF2CAP

D:\HW The startup file of the tracing

D:\HW iLMT\omu\workspace1\client\tracefile The running logs of the LMT.

OMU Work Mode

IP Addresses of the Host

Classification Operating Database Application Software

Host Application Linux OS OMU Application software for

Application Linux OS OMU Application software for service

Background Client Windows OS of - Applicant software for the LMT:

Classification Operating Database Application Software

Applicant Linux OS OMU Server software for PM and CM. For

Table 1 Directories on the FTP client

Directory on the FTP Client Directory on the OMU Server Descrip

Software package (auto loading) /opt/pub/software/tmp Stores

Directory on the FTP Client Directory on the OMU Server Descrip

License file (/opt/pub/software/tmp) /opt/pub/software/tmp Stores

ISO file (/opt/pub/software/tmp) /opt/pub/software/tmp Stores

Memory dump file /opt/HUAWEI/cgp/workshop/omu/share/dm Stores

Firmware file /opt/HUAWEI/cgp/workshop/omu/workspac Stores

Directory on the FTP Client Directory on the OMU Server Descrip

ME file /opt/HUAWEI/cgp/workshop/omu/share/nefil Stores

OMU run log /opt/HUAWEI/cgp/workshop/omu/share/run Stores

DEV log /opt/HUAWEI/cgp/workshop/omu/share/run Stores

DB log /opt/HUAWEI/cgp/workshop/omu/share/run Stores

OS log (/var/log) /var/log Stores

Export file /opt/HUAWEI/cgp/workshop/omu/share/exp Stores

Directory on the FTP Client Directory on the OMU Server Descrip

Device file /opt/HUAWEI/cgp/workshop/omu/share/devi Stores

Release call record /opt/HUAWEI/cgp/workshop/omu/share/rele Stores

Backup /opt/HUAWEI/cgp/workshop/omu/share/bac Stores

Peer information /opt/HUAWEI/cgp/workshop/omu/share/pee Stores

Installation log (/opt/pub/log) /opt/pub/log Stores

Directory on the FTP Client Directory on the OMU Server Descrip

Read-only ME file /opt/HUAWEI/cgp/workshop/omu/share/nefil Stores

UA file /opt/HUAWEI/cgp/workshop/omu/share/om Stores

Other important directories

Table 2 Other important directories

/opt/HUAWEI/cgp/uninstall Stores the script used to uninstall the OMU.

/opt/HUAWEI/cgp/version Stores all the software packages to load on

the information about software packages

/opt/HUAWEI/cgp/workshop/rollback Stores the script used to switch the

/opt/HUAWEI/cgp/workshop/nes/ne[ME ID] Stores the installation directory of a service

/opt/HUAWEI/cgp/workshop/omu/workspace[workspace Stores the work directory of the OMU. You

/opt/HUAWEI/cgp/workshop/omu/data Stores the data files of the OMU database.

Subsystem Module Name Module Name Function Description

OMU CM Configuration Used for data configuration. The CM

FM Fault Manages faults for location and

PM Performance Collects and displays performance