Anda di halaman 1dari 126

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.
Table 1 LMT Processes Function description

Function Name Function Description

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
Table 1 LMT Processes Function description

Function Name Function Description

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
Table 1 Directories on the FTP client

Directory on the FTP Client Directory on the OMU Server Descrip


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
Table 1 Directories on the FTP client

Directory on the FTP Client Directory on the OMU Server Descrip


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
Table 1 Directories on the FTP client

Directory on the FTP Client Directory on the OMU Server Descrip


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
Table 1 Directories on the FTP client

Directory on the FTP Client Directory on the OMU Server Descrip


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.
Table 1 Modules of the O&M subsystems

Subsystem Module Name Module Name Function Description


(Acronym/Abbreviation) (Expansion)

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
Table 1 Modules of the O&M subsystems

Subsystem Module Name Module Name Function Description


(Acronym/Abbreviation) (Expansion)

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 5 Login interface (2)

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.
Yes: No further action is required.
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.
Yes: No further action is required.
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.
22. Log in to the client again, and check whether the login is successful.
Yes: No further action is required.
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.
27. Log in to the client again, and check whether the login is successful.
Yes: No further action is required.
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.
34. Log in to the client again, and check whether the login is successful.
Yes: No further action is required.
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.
36. Log in to the client again, and check whether the login is successful.
Yes: No further action is required.
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.
38. Log in to the client again, and check whether the login is successful.
Yes: No further action is required.
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 20 Login interface (3)

Figure 21 Server Management dialog box (2)


Figure 22 Setting the common login mode

40. Log in to the client again, and check whether the login is successful.
Yes: No further action is required.
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.
Yes: No further action is required.
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.
Impact on the System
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

Additional Information
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:

Click on the toolbar. The Confirm dialog box is displayed. Click OK.
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
Impact on the System
Prerequisites
Procedure
Additional Information
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.
Impact on the System
This operation has no adverse impact on the system.
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.
Additional Information
Related Tasks
You can log in to the client again in offline mode in three ways:

Click on the toolbar. The Confirm dialog box is displayed. Click OK.
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:

Click on the toolbar. The Confirm dialog box is displayed. Click OK.
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
Impact on the System
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.
Impact on the System
This operation has no adverse impact on the system.
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.
The default value is 2000.
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.
The default value is 2048.

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.
By default, this option is selected.

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.
By default, this option is selected.

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
Table 1 Status description

Category Color Status Description

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.
Table 1 Status description

Category Color Status Description

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
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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
thousand subscribers or 1380 kBHSA; a pair of UPBA0
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
thousand subscribers or 1380 kBHSA; a pair of UPBA0
boards supports 1 million subscribers or 2760 kBHSA.
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
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
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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
thousand subscribers or 1380 kBHSA; a pair of UPBA0
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.

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
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


Board Board
Type Type

be deployed in conjunction with the boards of other


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
application type must be deployed in conjunction with
the boards of other application types.
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
be deployed in conjunction with the boards of other
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
be deployed in conjunction with the boards of other
application types.
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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
be deployed in conjunction with the boards of other
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
application type must be deployed in conjunction with
the boards of other application types.
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
be deployed in conjunction with the boards of other
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
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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
application type performs only the service functions. It
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
often deployed on a UPB0 (front board).
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
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


Board Board
Type Type

office, and tandem office entity. This application type is


often deployed on a UPB0 (front board).
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
functions of the MGCF, gateway office, and tandem
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


application type performs message dispatching,
protocol processing, gateway control, and data
management. It must be deployed in conjunction with
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
application type performs only the service functions. It
must be deployed in conjunction with the UGUCU and
UGUCG to provide the functions of the MGCF,
gateway office, and tandem office entity with
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


Board Board
Type Type

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
often deployed on a UPB0 (front board).
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
office, and tandem office entity. This application type is
often deployed on a UPB0 (front board).
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


application type performs message dispatching,
protocol processing, gateway control, and data
management. It must be deployed in conjunction with
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,
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
application type performs only the service functions. It
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
often deployed on a UPB0 (front board).
UGMIU: minimum unit. A board of this application type
is an integrated deployment for a system of
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


Board Board
Type Type

comparatively small capacity. This application type is


deployed to provide functions of the MGCF, gateway
office, and tandem office entity. This application type is
often deployed on a UPB0 (front board).

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
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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


application type can house multiple network entities
UPBA2 USIA1 such as the HSS, USCDB, and ATS.
MNAEN: assembled elements N. A board of this
application type can house multiple network entities
such as the OMU, SPG, and CCF.
MNAOM: assembled elements OM. A board of this
application type can house multiple network entities
such as the OMU and SPG.
MNAHU: assembled elements HU. A board of this
application type can house multiple network entities
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
application type can house multiple network entities
such as the HSS and USCDB.
MNAER: assembled elements R.
MNAET: assembled elements T. A board of this
application type can house multiple network entities
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


application type can house multiple network entities
UPBA6 USIA1 such as the HSS, USCDB, and ATS.
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


Board Board
Type Type

MNAEN: assembled elements N. A board of this


application type can house multiple network entities
such as the OMU, SPG, and CCF.
MNAOM: assembled elements OM. A board of this
application type can house multiple network entities
such as the OMU and SPG.
MNAHU: assembled elements HU. A board of this
application type can house multiple network entities
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
application type can house multiple network entities
such as the HSS and USCDB.
MNAER: assembled elements R.
MNAET: assembled elements T. A board of this
application type can house multiple network entities
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.
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


application type can house multiple network entities
UPBA6 USI2 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.

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


application type can house multiple network entities
UPBA6 USI7 such as the OMU, SPG, and CCF.
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


Board Board
Type Type

MNAOM: assembled elements OM. A board of this


application type can house multiple network entities
such as the OMU and SPG.

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


application type can house multiple network entities
such as the OMU, SPG, and CCF.
MNAOM: assembled elements OM. A board of this
application type can house multiple network entities
such as the OMU and SPG.
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.

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


application type can house multiple network entities
such as the OMU, SPG, and CCF.
MNAOM: assembled elements OM. A board of this
application type can house multiple network entities
such as the OMU and SPG.
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.
MNAHU3: assembled elements HU. The HSS and
USCDB can be deployed together on this board.
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).

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


application type can house multiple network entities
such as the HSS, USCDB, and ATS.
MNAEN: assembled elements N. A board of this
application type can house multiple network entities
such as the OMU, SPG, and CCF.
MNAOM: assembled elements OM. A board of this
application type can house multiple network entities
such as the OMU and SPG.
MNAHU: assembled elements HU. A board of this
application type can house multiple network entities
such as the HSS and USCDB.
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


Board Board
Type Type

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
application type can house multiple network entities
such as the HSS and USCDB.
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.

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


application type can house multiple network entities
such as the HSS, USCDB, and ATS.
MNAEN: assembled elements N. A board of this
application type can house multiple network entities
such as the OMU, SPG, and CCF.
MNAOM: assembled elements OM. A board of this
application type can house multiple network entities
such as the OMU and SPG.
MNAHU: assembled elements HU. A board of this
application type can house multiple network entities
such as the HSS and USCDB.
MNAEZ: assembled elements Z. A board of this
application type can house any network entities for
commissioning.
MNAHU3: assembled elements HU. The HSS and
USCDB can be deployed together on this board.

UPBA0 USI1 MNAET: assembled elements T. A board of this


application type can house multiple network entities
UPBA0 USI2 such as the HSS, USCDB, and ENS.

UPBA0 USIA1 MNAER: assembled elements R. A board of this


application type can house multiple network entities
such as the ATS and CSCF.
MNAET: assembled elements T. A board of this
application type can house multiple network entities
such as the HSS, USCDB, and ENS.

UPBA0 USIA7 MNAER: assembled elements R. A board of this


application type can house multiple network entities
such as the ATS and CSCF.
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


Board Board
Type Type

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


application type can house multiple network entities
such as the HSS and USCDB.
MNAHU3: assembled elements HU. The HSS and
USCDB can be deployed together on this board.

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


application type can house multiple network entities
such as the HSS and USCDB.
MNAHU3: assembled elements HU. The HSS and
USCDB can be deployed together on this board.
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).

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.
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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


type provides the voice and video conference services,
UPBA2 USIB0 including the management of voice and video
conferences, conference scheduling, and conference
UPBA6 USIA1 control. The MMU provides a Web portal to conference
subscribers and invokes the MRS to provide resources
UPBA6 USIB0 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
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


type provides the voice and video conference services,
including the management of voice and video
conferences, conference scheduling, and conference
control. The MMU provides a Web portal to conference
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


Board Board
Type Type

subscribers and invokes the MRS to provide resources


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
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
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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
application type integrates the functions of the DRU,
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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
application type integrates the functions of the DRU,
DSU, and data storage device management. Such a
board is not configured with disk arrays.
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
management unit. PGW, the access point between the
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
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


Board Board
Type Type

data in the USCDB database and the physical storage


management function for storing data on disk arrays.
USDMU2: data management unit. The DMU manages
the data storage devices, that is, the disk arrays.
USDMU3: 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


application type integrates the functions of the DRU,
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
application type integrates the functions of the DRU,
DSU, and physical data storage management. Such a
board is configured with disk arrays.
USDMU: data management unit. The DMU manages
the data storage devices, that is, the disk arrays.
USDMU2: data management unit. The DMU manages
the data storage devices, that is, the disk arrays.
USDMU3: data management unit. The DMU manages
the data storage devices, that is, the disk arrays.
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
application type integrates the functions of the DRU,
DSU, and data storage device management. Such a
board is not configured with disk arrays.
USPID3: The USPID3 boards are used for data
services and service provision. The data are stored on
the local hard disks.
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


Board Board
Type Type

UPB0 USI1 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.
USDPU: dispatching unit. This type of application
forwards IP packets. It receives and transmits
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.
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 VAS systems to access the
USCDB. It provides standard LDAP interfaces 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.

UPB0 USIA1 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.
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 VAS systems to access the
USCDB. It provides standard LDAP interfaces 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
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


Board Board
Type Type

USCDB database. The PGW can work in


active/standby mode.

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


management unit. PGW, the access point between the
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
management unit. PGW, the access point between the
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.

GPU0 USI0 USDMU: data management unit. The DMU manages


the data storage devices, that is, the disk arrays.
USDMU2: data management unit. The DMU manages
the data storage devices, that is, the disk arrays.
USDMU3: data management unit. The DMU manages
the data storage devices, that is, the disk arrays.
USDPU: dispatching unit. This type of application
forwards IP packets. It receives and transmits
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.
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.
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 VAS systems to access the
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


Board Board
Type Type

USCDB. It provides standard LDAP interfaces for third-


party VAS systems to access data in the USCDB.
USPMU: It refers to the provisioning system and data
management unit. PGW, the access point between the
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
management unit. PGW, the access point between the
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.
USPID3: The USPID3 boards are used for data
services and service provision. The data are stored on
the local hard disks.

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
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.
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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
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.
USPID3: The USPID3 boards are used for data
services and service provision. The data are stored on
the local hard disks.
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 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
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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.
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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
an integration of all HSS modules.
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


an integration of all HSS modules.
UPBA2 USIB0

UPBA6 USIB0

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


an integration of all HSS modules.
UPBA0 ETIA2

UPBA0 SSIA0
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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,
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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


Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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
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.

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.
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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
routing and storage.
MNUFE: integrated FE application type of SingleSDB.
It consists of the following application types:
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.
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.


It consists of the following application types:
UPBA6 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.
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
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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.
It consists of the following application types:
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.

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
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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.
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


Board Board
Type Type

UPB1 USIA7 UAMU: service processing unit of the UIM. The UAMU
boards are used to perform the authentication.
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.

UPBA2 ETIA0 UIMU: UIM signaling processing unit. This unit is used
to set up connections with other access devices and
UPBA2 ETIA2 implements signaling service processing to complete
authorization, authentication, and accounting. The
UPB0 ETIA0 UIMU consists of two functional modules, namely, the
signaling access unit and the service processing unit.
UPB0 ETIA2 UAMU: service processing unit of the UIM. The UAMU
boards are used to perform the authentication.
UPBA6 ETIA0 UMHU: service processing unit. The UMHU boards of
the UIM are used to process signaling sent from the
UPBA6 ETIA2 HLR.
UMSU: service processing unit of the UIM. The UMSU
boards are used to perform the authentication and
provides interface for short message processing.
UTAU: The UIM and USCDB can be deployed together
on this board.

UPB0 USIA1 UIMU: UIM signaling processing unit. This unit is used
to set up connections with other access devices and
implements signaling service processing to complete
authorization, authentication, and accounting. The
UIMU consists of two functional modules, namely, the
signaling access unit and the service processing unit.
UAMU: service processing unit of the UIM. The UAMU
boards are used to perform the authentication.
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.
UPSU: Portal processing unit of the UIM.
UTAU: The UIM and USCDB can be deployed together
on this board.
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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
boards are used to perform the authentication.
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.
UPSU: Portal processing unit of the UIM.
UTAU: The UIM and USCDB can be deployed together
on this board.
UCSU: UIM NE SSO processing unit, this unit performs
single sign-on authentication feature.

UPBA2 USI1 UPSU: Portal processing unit of the UIM.


UTAU: The UIM and USCDB can be deployed together
UPB0 USI1 on this board.
UCSU: UIM NE SSO processing unit, this unit performs
UPBA6 USI1 single sign-on authentication feature.

UPBA0 USIA1 UIMU: UIM signaling processing unit. This unit is used
to set up connections with other access devices and
UPBA0 USIB0 implements signaling service processing to complete
authorization, authentication, and accounting. The
UIMU consists of two functional modules, namely, the
signaling access unit and the service processing unit.
UAMU: service processing unit of the UIM. The UAMU
boards are used to perform the authentication.
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.
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.
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


Board Board
Type Type

UPBA0 USIA7 UAMU: service processing unit of the UIM. The UAMU
boards are used to perform the authentication.
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.
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.

UPBA2 USIA1 UIMU: UIM signaling processing unit. This unit is used
to set up connections with other access devices and
UPBA2 USIB0 implements signaling service processing to complete
authorization, authentication, and accounting. The
UPBA6 USIA1 UIMU consists of two functional modules, namely, the
signaling access unit and the service processing unit.
UPBA6 USIB0 UAMU: service processing unit of the UIM. The UAMU
boards are used to perform the authentication.
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.
UPSU: Portal processing unit of the UIM.
UTAU: The UIM and USCDB can be deployed together
on this board.
UCSU: UIM NE SSO processing unit, this unit performs
single sign-on authentication feature.
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.
UBAU3: board on which the USCDB and the UIM
serving as the UBSF and UAPU are deployed. It is
used for Utinterface authorization.
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


Board Board
Type Type

UPBA2 USIA7 UAMU: service processing unit of the UIM. The UAMU
boards are used to perform the authentication.
UPBA6 USIA7 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.
UPSU: Portal processing unit of the UIM.
UTAU: The UIM and USCDB can be deployed together
on this board.
UCSU: UIM NE SSO processing unit, this unit performs
single sign-on authentication feature.
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.
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
application manages and maintains the resources,
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.
The boards of this application type must be deployed in
conjunction with the boards of other application types.

UPBA0 USI1 UPRPU: resource process unit of UPCC. This type of


application manages and maintains the resources,
policies, charging rules, and routing data of the UPCC.
The boards of this application type must be deployed in
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.
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


Board Board
Type Type

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


application manages and maintains the resources,
policies, charging rules, and routing data of the UPCC.
The boards of this application type must be deployed in
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.
UPCSPU: cable service processing unit of the UPCC.
This type of application provides the service
processing function of the UPCC in a cable network.
The boards of this application type must be deployed in
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.
The boards of this application type must be deployed in
conjunction with the boards whose application type is
UPCSPU.

UPBA0 USIB0 UPIRU: integrative resource unit of UPCC. This type of


application controls the resources and policies of the
UPBA2 USIB0 UPCC.

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


of application provides policies and the UPCC WebUI.
UPBA2 USIA1 The boards of this application type must be deployed in
conjunction with the boards of other application types.
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
of application provides policies and the UPCC WebUI.
The boards of this application type must be deployed in
conjunction with the boards of other application types.

UPBA6 USIB0 UPIRU: integrative resource unit of UPCC. This type of


application controls the resources and policies of the
UPCC.

AGCF(AGCF) UPBA0 USIA1


Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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.
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


Board Board
Type Type

UPBA0 ETIA0 SDAU: basic signaling route processing unit of the


SPS. It contains IFM, DAU, BSG, SSU, DCU, and DSG
UPBA0 ETIA2 processes and is the basic configuration for the SPS to
process Diameter and STP signaling.

UPBA0 USIB0 SDAU: basic signaling route processing unit of the


SPS. It contains IFM, DAU, BSG, SSU, DCU, and DSG
processes and is the basic configuration for the SPS to
process Diameter and STP signaling.
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.
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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,
Table 1 Mapping between MEs, board types, and application types

ME type Front Back Application Type


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
Power distribution box
Note

This command does not apply to the optical modules connected to FC ports.

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
Power distribution box
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.
This command does not apply to the optical modules connected to FC ports.
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.