NMS U2000 Training

NMS
Prepared By Abhishek Jain (45007) and Amit Akshantal (45783).
The contents here are for Aricent internal training purposes only and do not carry any commercial
value
The iManager M2000 V2 system (M2000) is a centralized network
management (NM) product developed by Huawei. As a wireless
NM solution, the M2000 performs centralized NM to all the
wireless products of Huawei.
This document comprises the overview, system architecture,

typical configuration, and networking of the M2000.
The contents here are for Aricent Group internal training purposes only and do not carry any commercial value
This helps you to familiarize yourself with:
Overview of the M2000
System architecture of the M2000
Typical system configuration of the M2000
Networking of the M2000
Reference
M2000 Product Description
Chapter 1 Overview of the M2000
Chapter 2 System Architecture of the M2000
Chapter 3 Typical System Configuration of the M2000
Chapter 4 Networking of the M2000
Overview of the M2000
The iManager M2000 Mobile Element Management System (M2000) is a

centralized mobile network management platform developed by Huawei
The M2000 can perform centralized management on mobile NEs provided by
Huawei. These NEs include NEs on the UMTS, GSM, CDMA, WiMAX, and core
networks. In addition, the M2000 manages the IP networking devices (Huawei
device) used in the mobile network.
Position of the M2000 on the Network
NML
NMS
Northbound interface
Functions
FM PM CM TM SM SWM SYM NBI
EML Features
CME iWeb
iManager
NHC
M2000
iSStar
Message LMT
Trace
Data center
iManager M2000
Southbound interface
NEL MSC UMG PDSN CG

CN
SGSN HL
R
Router Lanswitch
BTS BSC
GBSS IP device
WASN BTS
S-CSCF Wimax
NodeB RNC
UTRAN MGCF
IMSBGCF
NM Interfaces
Northbound interface NMS

Standard CORBA interface
Complying with the 3GPP R6
Supporting the management of alarm, performance, and
configuration
File interface
Including configuration file interface, performance file
interface, alarm file interface, and inventory file interface
ASC II alarm streaming interface FILE SNMP CORBA ASC
Supporting real-time alarm
Providing mechanism for alarm synchronization and for
detecting the connection status of alarm links
SNMP interface iManager M2000
Supporting real-time alarm reporting, query of current
alarms, and heartbeat notification
Supporting the SNMPv1, SNMPv2c, and SNMPv3 protocols
MML Transmission interface Inner interface
Supporting configuration and performance management
NE NE NE
Southbound interface
Indicating the internal interfaces connected to NEs
The iManager M2000 V2 Solution
Providing solutions for the Huawei UMTS/GSM/CDMA/WiMAX products
UMTS GSM CDMA WiMAX
NodeB MSC MSC BS

RNC BSC MSC Server ASN-GW
SGSN BTS MGW AAA server
GGSN PCU PDSN
MSC HLR HLR
Server BSC
MGW BTS
HLR RAC
CG RAU
TSC
Features of the iManager M2000 V2
Wireless-network-based NM solution
Together with the LMT, the M2000 performs centralized maintenance and NM to NEs at the server and
client levels.
The M2000 provides the NMS with multiple Northbound interfaces for communicating with the NMS;
thus managing networks at different levels.
Centralized management
The M2000 performs centralized O&M for NEs.
The M2000 supports topology management, centralized configuration, centralized performance,
centralized fault, log management, and security management.
Flexible network architecture

The M2000 is connected to NEs through the TCP/IP protocol.
Reasonable system architecture

The M2000 features a modular design; thus enabling smooth network expansion.
The M2000 adopts an open system architecture, which eases the connection to NEs
Topology of the M2000 Network
Northbound interface
M2000 server
Remote terminal
Client
NMS
NM center
Alarm box IP over Ethernet,

Alarm box
E1,DDN and X.25 Area 2
Area 1
Client Client 1 Client 2
IP Bearing
Network
LMT RNC LMT
MG MG NodeB
Area 1 MSC HLR W Area 2
W
System Architecture of the M2000
Software of the M2000
M2000 server software

M2000 client software: providing a graphical user interface (GUI); performing O&M on
managed NEs
NE mediation software: connecting the NEs of the M2000 V2 to the mediation layer
Hardware of the M2000
M2000 servers
M2000 clients
Alarm boxes and networking devices
M2000 Software Modules
NMS
Northbound NMS interface
M2000 server
CORBA
Client
Sybase Server software
software
Solaris
CORBA
NE mediation NE mediation NE mediation

software 1 software 2 software n
NE 1 NE 2 NE n
Physical Architecture of the M2000
In the configuration
of the single-server
system (except the
N240), disk arrays
are contained.
Typical configuration of the M2000 system (single-server system)
Physical architecture in the HA system
Configuration of the M2000 system (SLS system)
3.1 System Configuration of the M2000
3.2 Overview of the Sun Servers
3.3 Overview of the Disk Arrays
Typical Configuration of the M2000
(Single-Server System)
Sun Sun Fire V890 Sun Fire E4900
Netra
240
CPU 2 CPUs/ 2 CPUs 4 CPUs 8 CPUs 4 CPUs 8 CPUs 12 CPUs
1.5 GHz /1.5 GHz /1.5 GHz /1.5 /1.5 /1.5 /1.5 GHz
GHz GHz GHz
Memory 4 GB 8 GB 16 GB 32 GB 16 GB 32 GB 32 GB
Hard disk 2*146 6*146 GB 2*146 GB
GB
Disk array None One 6140 disk array (16*146 GB Two 6140 disk arrays (16*146
/per 6140) GB /per 6140)
Accessories DVD ROM/Network card/DATA 72 tape drive/English documentation

Operating Solaris 10
system
Database Sybase 15.0.2
Application M2000 Server application software
software
Typical Configuration of the M2000 (HA
System)
Configuration Sun Fire V890 Sun Fire E4900
Number of CPUs 2 4 8 4 8 12
Clock frequency 1.5 GHz 1.5 GHz 1.5 GHz 1.5 GHz 1.5 GHz 1.5 GHz
Memory 8 GB 16 GB 32 GB 16 GB 32 GB 32 GB
Hard disk 6*146 GB 2*146 GB
Disk array Two 6140 disk arrays (16*146 GB Two 6140 disk arrays (16*146 GB /per
/per 6140) 6140)
Accessories DVD ROM/DATA 72 tape drive/English documentation
Operating system Solaris 10/English documentation
Application software M2000 Server application software
Disk management Sun Cluster
software
Typical Configuration of the M2000 (SLS
System)
Configuration Sun Netra 240 Sun Fire V890 Sun Fire E4900
Number of CPUs 2 8 8
Clock frequency 1.5 GHz 1.5 GHz 1.5 GHz
Memory 4 GB 32 GB 32 GB
Hard disk 2*146 GB 6*146 GB 2*146 GB
Disk array None One 6140 disk array One 6140 disk arrays (16*146 GB
(16*146 GB /per 6140) /per 6140)
Accessories DVD ROM/Network card/DATA 72 tape drive/English documentation
Operating system Solaris 10/ English documentation
Application M2000 Server application software
software
Disk management VCS
software
Typical Configuration of the M2000 Client
Item Recommended Configuration
CPU Pentium 2.8 GHz or faster
Memory 512 MB
Hard disk 80 GB
Item Recommended Configuration

Accessory DVDRW/FDD/network card/audio card/sound box/17'' LCD
monitor
Operating Windows XP Professional SP02 (Chinese version) or later
system
Application M2000 client application software

software
Application Scenario of the Server
No. Capability Server Type NE Type Number of Equivalent NEs
RNC+NodeB 50 cells = 1 equivalent NE

15 Sun Netra 240
1
equivalent NEs (2 CPUs)
MSC Server 6
45 Sun Fire V890 (2

2 MSC (Mobile Service Switching
equivalent NEs CPUs) 1
Center)
85 Sun Fire V890 (4 SGSN (Serving GPRS Support

2
3 Node)
equivalent NEs CPUs)
MGW (Media gateway) 1.4
110 Sun Fire E4900
4 HLR (Home Location Register) 0.1
equivalent NEs (4 CPUs)
GGSN (Gateway GPRS Support
0.1
160 Sun Fire V890 (8 Node)
5
equivalent NEs CPUs) CG (Charging gateway) 0.04
200 Sun Fire E4900 IWF (InterWorking function) 0.04

6
equivalent NEs (8 CPUs) SG (Signaling gateway) 0.5
Operation and Maintenance of M2000 Client
Developed independently by Huawei Technologies
Co., Ltd, the iManager M2000 V2 functions as
EMS in the Huawei wireless network solution. The
M2000 V2 can access a whole series of products
developed by Huawei and perform centralized
management on them.
This slide introduces the basic operations of on the

M2000 client.
After learning this course, you will have a basic knowledge of:
Basic operations on the M2000 client.
Operations related to monitoring management, topology management, security

management, log management, fault management, performance management,
software management, data management, and configuration management.
Reference
iManager M2000 System Description
iManager M2000 Administrator Guide
iManager M2000 Commissioning Guide
Chapter 1 Logging In to the M2000 Client
Chapter 2 Network Monitoring
Chapter 3 Topology Management
Chapter 4 Security Management
Chapter 5 Log Management
Chapter 6 Fault Management
Chapter 7 Performance Management
Chapter 8 Software Management
Chapter 9 Data Management
Chapter 10 Configuration Management
Logging In to the M2000 Client
Logging in to the The diagram on the left lists

M2000 server some basic operations involved
in M2000 client login.
Logging out
Exiting
Logging In to
Upgrading the the M2000
software on the client
Automatically
Other operations
Logging In to the M2000 Server
To log in to the M2000 server, choose Start > All programs > iManager M2000 client >
M2000 client.
Type the user name and password

in the corresponding fields.
Type the IP address of the M2000
server.
Note:
The initial user name is admin
and the password is null.
The user password is saved on
the M2000 server. Only when the
server is initially installed, the
password is null.
Logging In to the M2000 Server
|Main interface of the M2000 client|
Menu bar
Tool bar
Navigation
tree
Topology
view
Information
display
Status bar
Logging Out Off the M2000 Client
To log out off the M2000 client, choose System > Logout.
Note: Logging out

off the M2000
client does not
mean the
applications
running on the
M2000 client are
terminated.
Exiting
To exit the M2000 client, choose System > Exit.
Note: Exiting the

M2000 client
means the
applications
running on the
M2000 client are
terminated.
Upgrading the Software on the M2000 Client Automatically
To upgrade the software on the M2000 client automatically, perform the following steps:
Step 1: Start the M2000 client.
Step 2: Log in to the M2000 server.
After you log in to the M2000 server, the Confirmation dialog box is displayed, click Yes.
Prerequisites:
The M2000 can be automatically
and correctly upgraded only when:
The versions of the software on
the M2000 client and on the M2000
server are of the same version
sequence.
The version of the software on the
M2000 server is higher than that on
the M2000 client.
Upgrading the Software on the M2000 Client Automatically
Step 3: In the displayed Update Wizard dialog box, click Continue.
Other Operations
System Settings
Region Settings
Proxy Service Setting
LMT Prompt Setting
Metrology Setting
Broadcast Message
Change Password
Display/Hide/Customize
Toolbar
Lock Terminal
Region Settings
Number tab page

Time tab page
Date tab page
Time Mode tab page
Overview of Other Common Operations
System security settings
Single-user mode: indicates the system status

during the maintenance. The single-user mode allows
only one user to log in to the client and set up
sessions.
Multi-user mode: indicates the system status when
the system is functional. The multi-user mode allows
several users to log in to the client at the same time.
View license information
Download NE match files to the M2000 client
When the version of an NE on the M2000

client is different from that on the M2000
server, download the NE match file to the
M2000 client, as shown on the right.
If the files related to the new version of the
NE are not available, the system displays a
message, indicating that the system cannot
perform the upgrade operation.
Overview of the M2000 Network Monitoring
The M2000 network monitoring monitors the operational status of the M2000. For instance,
the monitoring management monitors the status of hard disk, database, session, or services.
The M2000 monitoring management involves the following operations:
Setting the server threshold
Monitoring the performance status of the server
Monitoring the hard disk status of the server
Monitoring the database status of the server
Monitoring the database serving status
Monitoring the process status of the server
Setting the Server Threshold
Step 1: Set the hard disk threshold.
Setting the Server Threshold
Step 2: Set the database threshold.
Monitoring the Performance Status of the Server
Monitoring the Hard Disk Status of the Server
Monitoring the Database Status of the Server
Monitoring the Database Serving Status
Monitoring the Process Status of the Server
Topology Management
The topology management is used for constructing and managing the topology structure of
the entire network. In this way, the networking topology and the operational status of the
entire network are displayed clearly.
Creating physical subnets
Creating physical NEs
Managing SNMP parameter template
Monitoring NEs
Adjusting the network topology
Adjusting the display of the topology view
Printing the topology view
Creating Physical Subnets
To create physical subnets, perform the following steps:
Step 1: Right-click the topology view and choose Create Physical Subnet from the
shortcut menu.
Create physical subnets

Create topological objects
Set background
The Create Topo Object

option is used to create
physical NEs, virtual NEs, IP
devices, virtual links, and
physical links.
Creating Physical Subnets
Step 2: Set the file server.
The file server is used for the file transfer between the M2000 and the NEs. An NE is used as the
file server to set up connections between the M2000 and other NEs. In this way, the problem that
the M2000 cannot set up direct connection with other NEs are solved.
Creating Physical NEs
Create a single physical NE.
Creating Physical NEs
Create multiple physical NEs.
For instance, the Search NodeB

function enables you to find the
NodeBs that belong to the RNC
on the topology view. Similarly,
you can set Search IMSOUT to
create multiple physical NEs
simultaneously.
Monitoring NEs
Monitor the NE status.
Monitoring NEs
Set NE reconnection status.
When the M2000 server is disconnected

from NEs, set the M2000 to re-connect NEs.
The NE reconnection has two statuses:
Forbidden connection
from an NE, the M2000 will not attempt to
connect the NE.
Permitted connection
from an NE, the M2000 attempts to re-
connect the NE. By default, a new NE is in
permitted connection status.
Disconnection icon:
Forbidden connection icon:
Monitoring NEs
Reconnect NE manually.
Adjusting Network Topology/Adjusting Network Topology Display/Printing
Topology View
Zoom in
Zoom out
Partially zoom in
Restore
Elements display
Print
View
Search
Save
Topology View
Adjust the NE position.
Topology View
View or modify the basic attributes of subnets.
Adjusting Network Topology/Adjusting Network Topology
Display/Printing Topology View
Search or modify the physical links.
To search for physical links,

double-click a physical link or a
physical link set on the topology
view.
In the displayed dialog box,
right-click a link and choose
Link Browser.
Delete a subnet. Delete an NE.
Customize the display of topology alarms.
Topology View
Set the topology view to start the subnet.
The subnet view refers to that

displayed on the client after
the topology view is displayed.
If you do not plan to set the
topology view manually, the
default view of the subnet
started by the topology view is
the root subnet view.
M2000 Security Management
The M2000 security management involves the following operations:

Configuring the security management
Managing OM users
Managing NE users
Managing OM and NE users
Setting FTPS parameters
Interface of Security Management
Set the NE types to be

displayed.
Refresh the security

management interface.
Managing OM Users
Add an OM user group.
Managing OM Users
Authorizing OM User Group
Three default user groups are available on the

M2000 client. They are Administrators group,
Guests group, and Operators group.
The Administrators group has the highest
privileges. You cannot modify or copy the
privileges of the Administrator group. You can,
however, authorize the Guests group and the
Operators group.
Assigning privileges to OM user group

Assigning new device rights to OM user
group
Assigning MML command rights to
OM user group
Managing OM Users
Change password
Add OM users to OM user group
Bind OM user private rights
Assign MML command rights to OM

users
Synchronize OM user data
Note that each NE is assigned with the corresponding MML

command rights. When a new NE is added, you need to re-assign
the MML command rights for each user in the OM user group.
Managing OM Users
Set rules for NE type rights.
You can set the rules for NE

type rights in a template. After
setting the template, all the NEs
added have the rights inherited
from this template.
Managing NE Users
After the OM user is

bound with a real NE, you
can create at the NE side a
user with the same name as
the OM user. This user is
called NE user. The NE
user logs in to the NE
through the LMT.
Monitoring OM Users and NE Users
Monitor the OM Users.
Monitor the operations of OM users who are
now in session status.
When the M2000 server restarts or the network
is disconnected and restored, click Refresh to
refresh the session monitor table.
Monitor the sessions of the OM user on the LMT.
Note that this function is applicable only to NEs in

the WCDMA network and supports only the LMT
users.
Set the status for a non-default NE user.
By setting the status, the non-default

NE user's login and operation of the
MML commands on the LMT can be
controlled. Non-default NE users refer
to the NE local users excluding the
admin and guest users.
The statuses of non-default NE users
can be manageable and lock.
Force OM users to exit the M2000.
Force OM users to exit the LMT.
Unlocking OM users.
If the times that a user

enters wrong password at
a time exceeds the
maximum attempts, the
OM user is locked for a
period. Right-click the
user and choose Unlock
User from the shortcut
menu to unlock the user.
Set to lock an OM user automatically.
Setting FTPS Parameters
Encryption mode: self-adaptation mode, SSL encryption mode, and plain mode.
Supported mode: refers to the FTPS connection mode, mainly including active mode
and passive mode.
Transmission mode: refers to the mode in which the FTPS transfers files. The
transmission mode can be in ASCII mode or in text mode.
M2000 Log Management
Records significant events occurred

Types of logs in the system.
Records security events occurred in the Records all the

system, such as logging in to the M2000, important operations
modifying rights for OM user group, or performed by NE users
adding OM users. System log
Security NE operation
log log
Records all the important
operations performed by Records security events
OM users. occurred to NEs.
Types of NE
Operation log logs security
log
Notes:
Saved on the server background, the contents of a
Log template template are associated with users. For instance, the
templates created by user A can be seen by user A only.
Log query template The names of log templates that are of the same type and
1 belong to the same user cannot be duplicate. If the names of
log templates are duplicate, the system cannot save the
template.
A maximum of 40 characters are allowed for the name of
the template. The following characters are not allowed: `~!
Log statistics template @#$%^&*()\":;?,|{}
2
[]<>'
The template information node does not support dynamic
refresh. If user A logs in to two terminals at the same time
and delete or modify template 1 on terminal 1, the deletion or
modification cannot be performed on terminal 2
automatically. The manual refresh provided by the system,
however, enables you to refresh the template information
manually.
Operations involved in the M2000 log management are as follows:

Querying logs
Collecting statistics on logs
Managing log templates
Querying Logs
Querying operation logs

Querying system logs
Querying security logs
Querying NE Querying NE operation logs

security logs
Collecting Statistics on Logs
Collecting statistics on operation logs
Collecting statistics on system logs
Collecting statistics on security logs
Collecting statistics on NE operation logs

Collecting statistics on NE
security logs
Managing Log Templates
Saving a template
Modifying
a template
M2000 Fault Management
Function
The M2000 reports, manages, and analyzes NE alarms in a centralized manner. The M2000 collects NE alarms to the
M2000 and displays different audio and video device alarms for the maintenance personnel. In addition, the M2000
notifies the maintenance personnel of device alarms by short message or email at the time when the alarm is
generated.
Operations:
The following operations and analysis can be performed on NE alarms at the M2000 side.
Manual restore
Filtering
Severity redefinition
Alarm relevance
In this way, the M2000 can perform centralized analysis and processing on the device alarms generated in the current
network.
Critical
Indicates that the device or the
M2000 Fault Management resource cannot be used

completely and needs to be
restored immediately.
Alarm Major
Indicates that the quality of the
severity device or the resource is severely
damaged. Corrective measures
should be taken immediately.
Minor
Fault Indicates that the quality of the
Management device or the resource is slightly
affected.
Prompt
Indicates that the quality of the
device or the resource may
Alarms can be related to the following items: probably be affected.
Power supply system
Environment system Alarm Event alarm
Signaling system category Refers to the notification generated
Relay system when the system detects the events
occurred.
Hardware system
Software system
Fault alarm
Operating system Refers to the notification generated
when the system detects the faults
Telecommunications system occurred.
Service quality
Alarm
Fault handling
type
Internal alarm
Saving alarms
In the alarm database, four tables are available for saving alarms. The four tables are as follows:
tbl_cur_alm: saves currently generated alarms.
tbl_his_alm: saves alarms generated in the past.
tbl_event: saves the event alarms.
tbl_mask_alm: saves the shielded alarms.
Mechanism for Processing Alarm Table
Overflow
By default, the alarm service detects whether the number of alarms in the alarm table reaches to the upper
threshold every 83 seconds after it is started.
The upper threshold for each alarm table is as follows:
tbl_cur_alm: 100, 000
tbl_his_alm: 2 million and can be modified through the M2000 client.
tbl_event: 200 million and can be modified through the M2000 client.
tbl_mask_alm: 200, 000
Mechanism for Processing Alarm Table
Overflow
When the alarms recorded in the alarm table exceed the threshold, different alarm tables have different
mechanisms to process alarm table overflow.
tbl_cur_alm: sorts the alarms by alarm generation time in sequence and forcibly changes first ten thousand
unacknowledged and cleared alarms to the tbl_his_alm. If the alarm table still has the problem of overflow, move the
earliest unacknowleged and uncleared alarms to the tbl_his_alm.
tbl_his_alm: sorts the alarms by alarm generation time in sequence and documents the 20 percent of the earliest
alarms. Then, the system deletes these earliest alarms automatically.
tbl_event: sorts the alarms by alarm generation time in sequence and documents the 20 percent of the earliest alarms.
Then, the system deletes these earliest alarms automatically.
tbl_mask_alm: deletes the earliest 100,000 alarms from the alarm table.
Operations Involved in the M2000 Fault Management
Browsing current fault alarms

Browsing event Querying
alarms current
fault
alarms
Querying
event
alarms
Collecting
statistics on Querying
alarms history fault
alarms
Querying
shielded
alarms
Operations Involved in the M2000 Fault Management
Browsing current fault

alarms
Browsing event alarms
Setting alarm
services
Operations Involved in the
Redefining
Set alarm services. alarm severity
Acknowledging
Setting remote Setting
alarms
alarm conditions for
notification alarm filtering
Setting
alarm
correlation
analysis
Setting parameters
of remote alarm
notification
Performance Management
Measurement is a process during which the value of an attribute for an NE entity (including logical entity) in a period is
acquired.
Category of performance measurement counters
System counters: a kind of a default counter defined in the NE. System counters are categorized into common
counters and extended counters.
- Common counters: By default, the common counters are in the measurement state. Users cannot ignore any
measurement on common counters.
- Extended counters: By default, the extended counters are in the non-measurement state. Before performing any
measurement on extended counters, you need to activate them first. You can enable or disable the measurement on
extended counters.
Custom counters: refers to the counters that are defined on the M2000 client by users. The principle for customizing
counters is to perform arithmetic operations on the default counters, including common counters and extended
counters, in the system. In this way, custom counters are self-defined.
Results of Performance Measurement Statistics
The maximum saving days for the results whose measurement period is 5 minutes or 15 minutes are 7 and represented
by the parameter maxRTResultSavingDay.
The maximum saving days for the results whose measurement period is 30 minutes, 60 minutes, or 1 day are 30 and
represented by the parameter maxResultSavingDay.
The M2000 checks the results whose period is 30 minutes, 60 minutes, or 1 day on a fixed time 03:25 a.m. each day.
This is represented by the parameter capacityControlTime. The M2000 deletes the data saved for over 30 days.
The M2000 checks the results whose period is 5 minutes or 15 minutes on a fixed time 04:35 a.m. each day. This is
represented by the parameter capacityControlTime + 70 minutes. The M2000 deletes the data saved for over 7 days.
The parameters described previously are described in the file /export/home/omc/var/etc/conf/pmsvc.xml.
Measurement Settings
Open the
Measurement
Settings
window.
Setting Measurement
Change of
function sets
Change of
function
subset
Periods for the

selected function
subset
Two Counter ID
navigation
modes
Applying the
measurement
Objects
Several
NEs
Monitoring NE Performance
Querying missing measurement results of NEs

Synchronizing measurement results of NEs
Measurement management
Monitoring NE Performance
Monitor the integrity of measurement results of current NEs.
Querying Performance Measurement Results (I)
Query
template
Create a
query
Querying Performance Measurement Results (II)
Other settings, such as

querying the busy-hour
Setting results, measurement
an periods, sorting, and filter
object conditions
Setting
a
counter
Managing Measurement Objects
Importing the information

about measurement
objects
Exporting the
information about
measurement objects
Managing Measurement Objects
Activate/Suspend measurement tasks. Suspending
measurement Activating
tasks measurement
tasks
Managing User-Defined Counters
Creating user-defined
counters
Modifying user-
defined counters
Importing user-defined
counters
Exporting user-defined
counters
Managing Counter Threshold
Setting the counter Setting the

threshold Modifying the status of the
counter counter
threshold threshold
Monitoring NEs in Real Time
Software Management
The software management involves the following operations:

Managing the software and files
Upgrading NE software and patches
Managing RAN Licenses
Querying Version Information on Software Installed on the Server
Managing Software and Files
The file server is defined as follows:

If the M2000 plans to transfer files to NE B, the M2000 uploads files to the directory preset on NE A that supports
the FTP function. Then, NE B downloads the files from the preset directory from NE A. In such a situation, NE A is
defined as the file server of NE B.
NE A can server as the file server for itself.
Not all NEs can regard other NEs as their file server.
When the M2000 server serves as the file server for NEs, you can infer that the M2000 server can directly transfer
files with NEs.
Application scenarios
When the M2000 can serve only as ftp client because of limitations imposed by the firewall, NEs can regard itself or
other NEs as file server.
In case the NodeB can serve only as the FTP client and the network bandwidth between the M2000 and the RNC
should be saved, the RNC can take place of the NodeB to be the file server of the NodeB.
File File
A B
M2000-Server
Browsing the file information

on the server. The file
information includes software,
patches, license, data, and
others.
Transferring files
from the client to the
server
Transferring files
from the server to the
client
Transferring Transferring
files from files from the
NEs to the server to NEs
server
Upgrading NE Software and Patches
The software management function enables you to upgrade the software and patches of the following NEs:
RNC
NodeB
SGSN
GGSN
MSC server
MGW
ASN-GW
Note
For details about how to upgrade the RNC, the NodeB, and their corresponding
patches, refer to the upgrade guide.
Overview of Data Management: Backing Up NM Data
You can back up the NM data in two ways: periodic backup and manual backup.
You can back up the NM data through the full backup and the incremental backup. The following gives the difference
between the full backup and the incremental backup:
Each time when a full backup is performed, the M2000 removes all the previous files related to full backup and
incremental backup on the server and saves one and only the latest compressed full backup file. The file of full
backup is named in the following way: all-current time, such as, all-20060106103055.tar.gz.
Each time when an incremental backup is performed, a new backup file is generated. The incremental backup is on
the basis of previous backup data that can be a full backup or an incremental backup. The file of an incremental
backup is named in the following way: inc-current time, such as, inc-20060106103055.tar.gz.
The NM data to be backed up refers to the data contained the following files:
/export/home/omc/var/
/export/home/sysm/
The backup files of the NM data are saved in the directory of /export/home/backup/omc/ on the M2000 server.
Overview of Data Management: Backing Up NE Data
NE data backup: The data management provided by the M2000 enables you to back up the configuration files of all
NEs managed by the M2000 and the files that change dynamically during the operation.
You can back up the NE data in two ways: the periodic backup and the manual backup. The system can generate one
backup file after you perform the backup task once.
The maximum number of NE backup files stored on the server is determined by the M2000 configuration file. At
present, the M2000 server can store up to seven backup files for each NE. When more than seven backup files are
generated for an NE, the M2000 server stores only the latest seven backup files for this NE. Meanwhile, the M2000
server refreshes the backup file list.
The backup files of NE data are saved to the path: M2000 server/export/home/sysm/ftproot/NE type. Take the RNC
for example, /data type/NE FDN.
Overview of Data Management: NM Log
Data
When the M2000 system fails, you can run the diagnostic tool to collect all the related diagnostic information from the
M2000 server and client through the FTP protocol. By using this information, you can locate faults.
The collected information is as follows:
Trace files on the client, for example, Client_DebugTrace.
Java virtual machine thread stack and lock state of the client, for example, Client_ThreadStackDump.txt.
Trace files on the server, for example, iMAP.root.trace (to store the current trace
file) imap_stacks.20070206.170237.trace (to store history trace files before the currently collected NM log file).
Core files on the server, for example, core.imapsvcd.0.21221.1170824184.stack.
NE alarm synchronization number, for example, FMSyncNo.
The pstack file, for example, imap_stacks.20070207.155817.trace.
Information of the Sybase, for example, SybaseConfig.zip, SybaseVersion.zip, SYBLog.20070206.171040.zip.
Overview of Data Management: NM Log
Data
By default, the collected files are saved in M2000 client\iManagerM2000Client\diagnosis\collected files. You can
change the save path.
Data Management
Management
of server data Management of
NE data
Data Management
Backing
Refreshing Restoring NE
NE data
NE backup backup data up NE
management
data
data
Collecting NM Log Files
Step 1
Step 2: Set the FTP server.

Enter the IP address of M2000 server.
Enter the port number.
Enter the FTP user name and password used to log in to the target server.
Step 3: Select information to be collected.
If you plan to collect trace files on the client, trace files on the server, core files on the server, or trace files on the
local maintenance station, you should enter Start Time and End Time to collect the information within the specified
time range.
If you plan to collect alarm diagnostic data of the NE, enter the name of the NE whose alarm diagnostic data you
want collect in NE Name.
Step 4: Set the folder for saving the diagnostic information.

The collected files are saved under the M2000 client installation directory:
\iManagerM2000Client\diagnosis\collected files. You can change the directory for saving collected files.
Step 5: Click Collect to collect the diagnostic information.
If you click Stop when the diagnostic tool is collecting information from a client, you are not allowed to stop the
progress of collecting information from the client.
If you click Stop when the diagnostic tool is collecting information from the M2000 server, you are not allowed to
get any diagnostic information about the server.
Configuration Management
The operations involved in the configuration management vary with different products. For details about the operations
involved in the configuration management, refer to the iManager M2000 Operator Guide. This part only illustrates
how to start the LMT.
Starting the LMT
This document mainly describes the common M2000
maintenance operations, including the M2000 operation
commands and the Sybase operation commands.
This helps you to familiarize yourself with:
M2000 common operations and common logs

M2000 common maintenance commands
References
M2000 Administrator Guide
M2000 Software Installation Guide
OMCAtoStar User Manual
Chapter 1 Solaris Maintenance Commands
Chapter 2 Sybase Maintenance Commands
Chapter 3 M2000 Maintenance Commands
Chapter 4 M2000 Logs
Chapter 5 M2000 Log Collection Tool and Health

Check Tool
Solaris Maintenance Commands
Command Description
ifconfig a Display the IP address
ping Test if a IP or host is reachable
netstat an Display the ports status of server
netstat rn Display the routes of server
df -k Display the amount of disk space
du k Display the space occupied by files and directory
prstat Display the CPU and memory occupied by process

Check Tool
Sybase Maintenance Commands
Commands Description
showserver Display the status of Sybase database server
isql Start SQL script execution tool
select @@version Display the Sybase version
sp_helpdb Display the status of Sybase database

Check Tool
M2000 Maintenance Commands
Commands Description
start_svc Starting the entire M2000 system, including the system process and the service process (This
command is not applicable to the HA system.)
stop_svc Stopping the service process of the M2000 network management system (This command is
not applicable to the HA system.)
kill_svc Forcibly stopping the process of the M2000 network management system
svc_adm Managing M2000 services, such as starting, stopping, and querying services
displayVersion Display version of M2000 and installed mediation
scswitch Managing the system resource of HA system, such as starting/stop M2000, start/stop Sybase,
query M2000/Sybase
start_daem Starting the M2000 system daemon process (This command is not applicable to the HA
system.)
stop_daem Starting the M2000 system daemon process (This command is not applicable to the HA
system.)
daem_ps Display the status of M2000 system daemon processes

Check Tool
Collecting Information about the M2000 System
Solaris Log
Sybase Log
M2000 Server Log
M2000 Client Log
Core File
Solaris Log
Application Scenarios
Use the message log to familiarize yourself with the starting and stopping process of the system.
The hardware or other devices incur faults, such as the disk light is abnormal or the CPU and the memory cannot be found.
Brief Introduction of the Log

The log exists under the var/adm/messages directory.
The log records the information about the Sybase starting and stopping process, the operating status of the hardware and software, and the
main error information.
Under the /var/adm/ directory, there are messages, messages.0, messages.1, messages.2 , and messages.3. Where messages saves the
latest logs. Other message files are cyclically recovered.
# ls -al /var/adm/messages*
-rw-r--r-- 1 root root 311912 Dec 27 10:02 messages

-rw-r--r-- 1 root root 7840 Nov 19 15:34 messages.0

-rw-r--r-- 1 root root 170931 Oct 29 10:03 messages.3
Obtaining and Checking the Files

You can download the message log to the local computer through FTP and open it in .txt format.
You can check the files through the unix files such as more and cat.
Sybase Log
Use this log to familiarize yourself with the process of starting and stopping the Sybase.
The Sybase incurs faults, such as the Sybase cannot be started or errors occur during the operation.
Brief Introduction to the Log

Sybase12 version: The log exists under the /opt/sybase/ASE-12_0/install/ directory.
Sybase15 version: The log exists under the /opt/sybase/ASE-15_0/install/ directory.
The SYB.log and SYB_back.log files record the process of starting and stopping the Sybase and the main error
information.
Obtaining and Checking Files
You can download the log to the local computer through FTP and open it in .txt format.
You can check the files through the unix files such as more and cat.
M2000 Server Log trace
Use this log to familiarize yourself with the operating status of the M2000 services
and the information exchange between the services.
This log is required when the M2000 is faulty.
M2000 V2R3/V2R5 M2000 V2R6
Current Log /export/home/omc/var/logs
Log file iMAP.root.trace Each log file corresponds to one process , such as:
iMAP.cmserver_agent.trace
name iMAP.pm_agent.trace
iMAP.med_agent.trace

History trace /export/home/omc/var/logs/tracebak/

If log file is larger than 50 MB, the system automatically compresses it and transfers it to the
history trace directory
The file name contains detailed date and time, which refers to the time of the last log in the trace
file, such as:
iMAP.monitor_agent.trace.20080204122937.tar.gz
M2000 Client Log
Use this log to familiarize yourself with the operating status of the M2000 client and the operation records on the client.
The log is required when faults occur to the M2000 (especially when some problems occur only on the specified client).
Brief Introduction to the Log
The log exists under the .\client\tracefile\ directory.
For example, D:\iManagerM2000V200R005C01B024\client\tracefile
The file name contains the detailed time, which refers to the recorded time of the first log.
For example, DebugTrace_2007-08-27_16#21#20#991.txt
Obtaining and Checking Files

Assume that the M2000 is installed in the D:\iManagerM2000Client directory, then the trace information about the
foreground is saved in the D:\iManagerM2000Client\client\tracefile directory.
Thank You

NMS U2000 Training

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

NMS U2000 Training

Încărcat de

Drepturi de autor:

Formate disponibile

NMS

Prepared By Abhishek Jain (45007) and Amit Akshantal (45783).

This document comprises the overview, system architecture,

Overview of the M2000

System architecture of the M2000

Typical system configuration of the M2000

Networking of the M2000

M2000 Product Description

Chapter 2 System Architecture of the M2000

Chapter 3 Typical System Configuration of the M2000

Chapter 4 Networking of the M2000

The iManager M2000 Mobile Element Management System (M2000) is a

FM PM CM TM SM SWM SYM NBI

NEL MSC UMG PDSN CG

Northbound interface NMS

UMTS GSM CDMA WiMAX

NodeB MSC MSC BS

Flexible network architecture

Reasonable system architecture

Alarm box IP over Ethernet,

LMT RNC LMT

Chapter 2 System Architecture of the M2000

Chapter 3 Typical System Configuration of the M2000

Chapter 4 Networking of the M2000

M2000 server software

Hardware of the M2000

Northbound NMS interface

NE mediation NE mediation NE mediation

Typical configuration of the M2000 system (single-server system)

Physical architecture in the HA system

Configuration of the M2000 system (SLS system)

Chapter 2 System Architecture of the M2000

Chapter 3 Typical System Configuration of the M2000

Chapter 4 Networking of the M2000

3.1 System Configuration of the M2000

3.2 Overview of the Sun Servers

3.3 Overview of the Disk Arrays

Accessories DVD ROM/Network card/DATA 72 tape drive/English documentation

Item Recommended Configuration

CPU Pentium 2.8 GHz or faster

Item Recommended Configuration

Application M2000 client application software

3.1 System Configuration of the M2000

3.2 Overview of the Sun Servers

3.3 Overview of the Disk Arrays

No. Capability Server Type NE Type Number of Equivalent NEs

RNC+NodeB 50 cells = 1 equivalent NE

45 Sun Fire V890 (2

85 Sun Fire V890 (4 SGSN (Serving GPRS Support

200 Sun Fire E4900 IWF (InterWorking function) 0.04

3.1 System Configuration of the M2000

3.2 Overview of the Sun Servers

3.3 Overview of the Disk Arrays

This slide introduces the basic operations of on the

Basic operations on the M2000 client.

Operations related to monitoring management, topology management, security

iManager M2000 System Description

iManager M2000 Administrator Guide

iManager M2000 Commissioning Guide

Logging in to the The diagram on the left lists

Type the user name and password

|Main interface of the M2000 client|

Note: Logging out

To exit the M2000 client, choose System > Exit.