System Principle (V200R008C01 01)

HUAWEI MSOFTX3000 Mobile SoftSwitch Center
V200R008C01
System Principle
Issue
01
Date
2009-02-10
Huawei Proprietary and Confidential

Copyright Huawei Technologies Co., Ltd.
Huawei Technologies Co., Ltd. provides customers with comprehensive technical support and service. For any
assistance, please contact our local office or company headquarters.
Huawei Technologies Co., Ltd.

Address:
Huawei Industrial Base

Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website:
http://www.huawei.com
Email:
support@huawei.com
Copyright Huawei Technologies Co., Ltd. 2009. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions

and other Huawei trademarks are the property of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but the statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.


System Principle
Contents
Contents
About This Document.....................................................................................................................1
1 System Architecture...................................................................................................................1-1
1.1 Hardware Structure.........................................................................................................................................1-2
1.1.1 Hardware Composition..........................................................................................................................1-2
1.1.2 General Physical Structure.....................................................................................................................1-3
1.1.3 Service Processing Subsystem...............................................................................................................1-6
1.1.4 Maintenance Management Subsystem...................................................................................................1-7
1.1.5 Environment Monitoring Subsystem.....................................................................................................1-7
1.2 Logical Structure.............................................................................................................................................1-7
1.2.1 General Logical Structure......................................................................................................................1-8
1.2.2 Processor Subsystem..............................................................................................................................1-8
1.2.3 Switching Subsystem.............................................................................................................................1-9
1.2.4 Electromechanical Subsystem................................................................................................................1-9
1.2.5 Equipment Management Subsystem......................................................................................................1-9
1.3 System Bus Structure......................................................................................................................................1-9
1.3.1 IPMB Bus.............................................................................................................................................1-10
1.3.2 Base Bus...............................................................................................................................................1-12
1.3.3 Fabric Bus............................................................................................................................................1-13
1.4 Software Structure.........................................................................................................................................1-14
1.4.1 Overview of Software Architecture.....................................................................................................1-14
1.4.2 Host Software.......................................................................................................................................1-15
1.4.3 OMU Software.....................................................................................................................................1-15
1.5 System Process..............................................................................................................................................1-16
1.5.1 Host Process.........................................................................................................................................1-16
1.5.2 Background Process.............................................................................................................................1-17
2 Service Processing Subsystem.................................................................................................2-1

2.1 Processing of Signaling over IP......................................................................................................................2-2
2.1.1 Processing of Signaling over M2UA.....................................................................................................2-2
2.1.2 Processing of Signaling over M3UA.....................................................................................................2-4
2.1.3 Processing of Signaling over BICC.......................................................................................................2-5
2.1.4 Processing of Signaling over SIP...........................................................................................................2-7
2.1.5 Processing of Signaling over H.248.......................................................................................................2-8
Issue 01 (2009-02-10)

Contents

System Principle
3 Maintenance Management Subsystem..................................................................................3-1

3.1 Hardware Architecture....................................................................................................................................3-2
3.1.1 OMU.......................................................................................................................................................3-3
3.1.2 iGWB.....................................................................................................................................................3-3
3.1.3 Local Maintenance Terminal (LMT).....................................................................................................3-4
3.2 Software Architecture.....................................................................................................................................3-4
3.2.1 OMU Software.......................................................................................................................................3-5
3.2.2 LMT Software........................................................................................................................................3-8
3.3 Security Management....................................................................................................................................3-10
3.3.1 Command Groups................................................................................................................................3-10
3.3.2 Workstation Management....................................................................................................................3-11
3.3.3 Account Management..........................................................................................................................3-11
3.3.4 Login Time...........................................................................................................................................3-11
3.3.5 Lock Time............................................................................................................................................3-11
3.4 Data Management.........................................................................................................................................3-11
3.4.1 Storing OMU Data...............................................................................................................................3-12
3.4.2 Storing Host Data.................................................................................................................................3-12
3.4.3 Operating Data.....................................................................................................................................3-12
3.5 Loading Data.................................................................................................................................................3-14
3.5.1 Loading Options...................................................................................................................................3-14
3.5.2 Principles for Loading Data.................................................................................................................3-15
3.5.3 Procedure for Loading Data.................................................................................................................3-16
3.6 Software Patch Management.........................................................................................................................3-17
3.6.1 Basic Concepts.....................................................................................................................................3-17
3.6.2 Key Features.........................................................................................................................................3-18
3.6.3 Architecture..........................................................................................................................................3-19
3.6.4 Implementation.....................................................................................................................................3-20
4 Environment Monitoring Subsystem.....................................................................................4-1

4.1 Power Supply..................................................................................................................................................4-2
4.1.1 Power Input Unit....................................................................................................................................4-2
4.1.2 Power Distribution Unit.........................................................................................................................4-3
4.2 Monitoring Power Supplies.............................................................................................................................4-4
4.3 Monitoring Fan Boxes.....................................................................................................................................4-5
4.4 Monitoring the Environment of a Telecommunications Room......................................................................4-6
5 Alarm Management System.....................................................................................................5-1

5.1 Subsystems of the Alarm Management System .............................................................................................5-2
5.1.1 Fault Detection Subsystem.....................................................................................................................5-2
5.1.2 Alarm Generation Subsystem.................................................................................................................5-2
5.2 Alarm Severity and Alarm Type.....................................................................................................................5-3
5.2.1 Alarm Severity.......................................................................................................................................5-3
5.2.2 Alarm Type............................................................................................................................................5-4
5.3 Alarm Box and Alarm Console.......................................................................................................................5-4
ii

Issue 01 (2009-02-10)

System Principle
Contents
5.3.1 Alarm Box..............................................................................................................................................5-4

5.3.2 Alarm Console........................................................................................................................................5-5
5.4 Alarm Report Path...........................................................................................................................................5-5
5.4.1 Hardware Alarm Report Path.................................................................................................................5-5
5.4.2 Software Alarm Report Path..................................................................................................................5-6
5.5 Alarm Database...............................................................................................................................................5-6
5.5.1 Location of the Alarm Database.............................................................................................................5-7
5.5.2 Alarm Limitation Policy.........................................................................................................................5-7
6 Time Synchronization...............................................................................................................6-1
6.1 NTP Function..................................................................................................................................................6-2
6.1.1 Definition of NTP...................................................................................................................................6-2
6.1.2 Working Principles of NTP....................................................................................................................6-2
6.1.3 Networking of NTP................................................................................................................................6-4
6.2 Time Calibration Principles and Procedure....................................................................................................6-5
7 CDR and Charging.....................................................................................................................7-1

7.1 Basic Concepts................................................................................................................................................7-2
7.1.1 Charging Scheme...................................................................................................................................7-2
7.1.2 CDR Classification.................................................................................................................................7-3
7.1.3 CDR Interface........................................................................................................................................7-3
7.1.4 CDR Encoding.......................................................................................................................................7-4
7.2 CDR Generation..............................................................................................................................................7-4
7.2.1 CDR Generation Mechanism.................................................................................................................7-5
7.2.2 CDR Generation Process........................................................................................................................7-6
7.2.3 CDR Generation Scenarios....................................................................................................................7-8
7.3 CDR Delivery................................................................................................................................................7-14
7.3.1 CDR Delivery Process.........................................................................................................................7-14
7.3.2 Delivery Modes of Original CDRs.......................................................................................................7-15
7.3.3 Delivery Modes of Final CDRs............................................................................................................7-15
7.4 CDR Storage.................................................................................................................................................7-16
7.4.1 Storage of Original CDRs....................................................................................................................7-16
7.4.2 Storage of Final CDRs.........................................................................................................................7-17
7.5 CDR Backup.................................................................................................................................................7-18
7.5.1 Backup of Original CDRs....................................................................................................................7-19
7.5.2 Backup of Final CDRs (the First Copy)...............................................................................................7-19
8 Final CDRs...................................................................................................................................8-1
8.1 Types of Final CDRs.......................................................................................................................................8-2
8.2 Format of Final CDRs.....................................................................................................................................8-2
Issue 01 (2009-02-10)

iii

System Principle
Figures
Figures
Figure 1-1 Hardware composition of the MSOFTX3000....................................................................................1-3
Figure 1-2 Hardware configuration of the MSOFTX3000...................................................................................1-4
Figure 1-3 Physical structure of the MSOFTX3000............................................................................................1-5
Figure 1-4 Logical structure of the MSOFTX3000..............................................................................................1-8
Figure 1-5 System bus structure of the MSOFTX3000.....................................................................................1-10
Figure 1-6 Connections of IPMB buses.............................................................................................................1-11
Figure 1-7 Connections of the Base buses.........................................................................................................1-12
Figure 1-8 Connections of the Fabric buses.......................................................................................................1-13
Figure 1-9 Overall software architecture of the MSOFTX3000........................................................................1-14
Figure 1-10 Deployment of the host processes..................................................................................................1-16
Figure 1-11 Logical view of the background processes.....................................................................................1-18
Figure 2-1 Uplink processing path of signaling over M2UA...............................................................................2-3
Figure 2-2 Uplink processing path of signaling over M3UA...............................................................................2-4
Figure 2-3 Uplink processing path of signaling over BICC.................................................................................2-6
Figure 2-4 Uplink processing path of signaling over SIP....................................................................................2-7
Figure 2-5 Uplink processing path of signaling over H.248................................................................................2-9
Figure 3-1 Hardware architecture of the maintenance management subsystem..................................................3-2
Figure 3-2 Software architecture..........................................................................................................................3-4
Figure 3-3 Networking mode of the OMU...........................................................................................................3-6
Figure 3-4 Components of the OMU software.....................................................................................................3-7
Figure 3-5 Options for loading data...................................................................................................................3-14
Figure 3-6 Connections for loading data............................................................................................................3-15
Figure 3-7 Procedure for loading data................................................................................................................3-16
Figure 3-8 State transition of hot patches...........................................................................................................3-21
Figure 4-1 Power input unit..................................................................................................................................4-2
Figure 4-2 Electrical connections.........................................................................................................................4-3
Figure 4-3 Connections for monitoring power supplies.......................................................................................4-5
Figure 4-4 Monitoring fax boxes in an OSTA 2.0 subrack..................................................................................4-6
Figure 4-5 Structure of the monitoring system....................................................................................................4-6
Figure 5-1 Alarm generation subsystem..............................................................................................................5-3
Figure 5-2 Hardware alarm report path................................................................................................................5-6
Figure 6-1 Principle diagram of time synchronization.........................................................................................6-3
Figure 6-2 Calculating method for time offset and delay.....................................................................................6-4
Issue 01 (2009-02-10)


System Principle
Figures
Figure 6-3 Networking structure..........................................................................................................................6-5

Figure 6-4 Logical structure of the MSOFTX3000 time calibration system....................................................... 6-6
Figure 7-1 Structure of the MSOFTX3000 charging system...............................................................................7-5
Figure 7-2 Logical structure of the charging system............................................................................................7-6
Figure 7-3 Working process of the charging system............................................................................................7-7
Figure 7-4 Procedure for preprocessing CDRs by the iGWB..............................................................................7-8
Figure 7-5 Process of CDR generation and storage...........................................................................................7-15
Figure 7-6 Directory structure for the storage of original CDRs.......................................................................7-16
Figure 7-7 Directory structure for the storage of final CDRs............................................................................7-17
Figure 7-8 Format of a final CDR file................................................................................................................7-18
Figure 7-9 Implementation principle of CDR backup........................................................................................7-19
vi

Issue 01 (2009-02-10)

System Principle
Tables
Tables
Table 1-1 Network cable connections between subracks.....................................................................................1-6
Table 4-1 Mappings between the cabinet components and the switches.............................................................4-4
Table 7-1 Generation scenarios of original CDRs................................................................................................7-9
Issue 01 (2009-02-10)

vii

System Principle
About This Document
About This Document

Purpose
This document describes the functional structure and working principles of the
MSOFTX3000 (hereinafter referred to as the MSOFTX3000).
After reading this document, you should be able to know about the architecture and working
principles of various subsystems of the MSOFTX3000.
Related Versions
The following table lists the product versions related to this document.
Product Name
Version
MSOFTX3000
V200R008C01
Intended Audience
The intended audiences of this document are:
l
Network planning engineers
Network administrators
Organization
This document consists of 8 chapters and is organized as follows.
Issue 01 (2009-02-10)
Chapter
Description
1 System Architecture
This chapter describes the MSOFTX3000 with respect to

the hardware structure, logical structure, and software
structure.
2 Service Processing
Subsystem
This chapter describes the service processing subsystems

of the MSOFTX3000 with respect to the structure,
functions, and internal processing.


System Principle
About This Document
Chapter
Description
3 Maintenance Management
Subsystem
This chapter describes the maintenance management

subsystem of the MSOFTX3000 with respect to the
networking, structure, functions, and internal processing.
4 Environment Monitoring
Subsystem
This chapter describes the environment monitoring

subsystem and the power supply system of the
MSOFTX3000 with respect to the structure and functions.
5 Alarm Management System
This chapter describes the alarm subsystem of the

MSOFTX3000 with respect to the structure, composition
and briefs the alarm type, alarm level, alarm box, alarm
console, and the report paths of hardware alarms and
software alarms.
6 Time Synchronization
This chapter describes the clock synchronization system of

the MSOFTX3000 with respect to the features,
specifications, and implementation principles of clock
synchronization.
7 CDR and Charging
This chapter describes the billing system of the

MSOFTX3000 with respect to the structure,
implementation principles, and storage of original CDRs
and final CDRs.
8 Final CDRs
This chapter presents the formats of the final CDRs in

tables.
Conventions
Symbol Conventions
The following symbols may be found in this document. They are defined as follows.
Symbol
Description
Indicates a hazard with a high level of risk which, if not avoided,
will result in death or serious injury.
Indicates a hazard with a medium or low level of risk which, if
not avoided, could result in minor or moderate injury.
Indicates a potentially hazardous situation that, if not avoided,
could cause equipment damage, data loss, and performance
degradation, or unexpected results.
Indicates a tip that may help you solve a problem or save your
time.
Provides additional information to emphasize or supplement
important points of the main text.

Issue 01 (2009-02-10)

System Principle
About This Document
General Conventions
Convention
Description
Times New Roman
Normal paragraphs are in Times New Roman.
Boldface
Names of files, directories, folders, and users are in boldface.

For example, log in as user root.
Italic
Book titles are in italics.
Courier New
Terminal display is in Courier New.
Command Conventions
Convention
Description
Boldface
The keywords of a command line are in boldface.
Italic
Command arguments are in italic.
[]
Items (keywords or arguments) in square brackets [ ] are optional.
{ x | y | ... }
Alternative items are grouped in braces and separated by vertical

bars. One is selected.
[ x | y | ... ]
Optional alternative items are grouped in square brackets and

separated by vertical bars. One or none is selected.
{ x | y | ... } *
Alternative items are grouped in braces and separated by vertical

bars. A minimum of one or a maximum of all can be selected.
[ x | y | ... ] *
Optional items are grouped in brackets and separated by vertical

bars. Several items or no item can be selected.
GUI Conventions
Convention
Description
Boldface
Buttons, menus, parameters, tabs, window, and dialog titles are

in boldface. For example, click OK.
>
Multi-level menus are in boldface and separated by the ">" signs.

For example, choose File > Create > Folder.
Keyboard Operation
Issue 01 (2009-02-10)
Format
Description
Key
Press the key. For example, press Enter and press Tab.
Key 1+Key 2
Press the keys concurrently. For example, pressing Ctrl+Alt

+A means the three keys should be pressed concurrently.


System Principle
About This Document
Format
Description
Key 1, Key 2
Press the keys in turn. For example, pressing Alt, A means the
two keys should be pressed in turn.
Mouse Operation
Action
Description
Click
Select and release the primary mouse button without moving the
pointer.
Double-click
Press the primary mouse button twice continuously and quickly

without moving the pointer.
Drag
Press and hold the primary mouse button and move the pointer
to a certain position.
Update History
Updates between document versions are cumulative. Therefore, the latest document version
contains all updates made to previous versions.
Updates in Issue 01 (2009-02-10)

Initial release

Issue 01 (2009-02-10)

System Principle
System Architecture
About This Chapter

The MSOFTX3000 is a system built on the Open Standards Telecom Architecture Platform
(OSTA 2.0 platform).
1.1 Hardware Structure
The MSOFTX3000 comprises the power subrack, service processing subrack, service
processing unit, master rack monitoring unit (MRMU), local maintenance terminal (LMT), and
LAN switch.
1.2 Logical Structure
The MSOFTX3000 can be viewed as a system comprised of multiple logical subsystems from
the service logic perspective.
1.3 System Bus Structure
The system buses connect various subsystems of the MSOFTX3000. The subsystems exchange
information and communicate with each other through the system buses.
1.4 Software Structure
The MSOFTX3000 adopts the distributed software structure. The software functions are
distributed among the server boards and can be configured flexibly to meet the actual networking
requirements.
1.5 System Process
The system processes of the MSOFTX3000 can be classified into host process and OMU process.
Issue 01 (2009-02-10)

1-1

System Principle
1.1 Hardware Structure

The MSOFTX3000 comprises the power subrack, service processing subrack, service
processing unit, master rack monitoring unit (MRMU), local maintenance terminal (LMT), and
LAN switch.
1.1.1 Hardware Composition
The hardware of the MSOFTX3000 consists of the following: cabinet, power subrack, service
subrack, board, keyboard & video & mouse & switcher (KVMS), optionally MRMU, and LAN
Switch.
1.1.2 General Physical Structure
Physically, the MSOFTX3000 comprises various hardware components and cable connections.
1.1.3 Service Processing Subsystem
The service processing subsystem, also known as the host, is the core of the MSOFTX3000. It
comprises service processing subracks and service processing boards. It fulfills functions such
as service processing and resource management.
1.1.4 Maintenance Management Subsystem
The maintenance management subsystem, also known as the OMU, is composed of the active
and standby OMU boards, active and standby iGWB boards, LMT, and communication devices.
It fulfills functions such as O&M and CDR management.
1.1.5 Environment Monitoring Subsystem
The environment monitoring subsystem is comprised of the fan monitoring module of each
service processing subrack, and the power supply monitoring module and MRMU (optional) of
each cabinet. It is designed to ensure that the MSOFTX3000 operates in a normal environment.
1.1.1 Hardware Composition

The hardware of the MSOFTX3000 consists of the following: cabinet, power subrack, service
subrack, board, keyboard & video & mouse & switcher (KVMS), optionally MRMU, and LAN
Switch.
Figure 1-1 shows the hardware composition of the MSOFTX3000.
1-2

Issue 01 (2009-02-10)

System Principle
Figure 1-1 Hardware composition of the MSOFTX3000

1 Cabinet
MRMU
LAN Switch
KVMS
Subrack
PDB
1.1.2 General Physical Structure

Physically, the MSOFTX3000 comprises various hardware components and cable connections.
Figure 1-2 shows the hardware configuration of the MSOFTX3000.
Issue 01 (2009-02-10)

1-3

System Principle
Figure 1-2 Hardware configuration of the MSOFTX3000

Integrated configuration cabinet(46U)
Power distribution box(3U)
Subrack 1(14U)
MRMU(1U)
LAN Switch 1(1U)
LAN Switch cabling trough(1U)
LAN Switch 0(1U)
LAN Switch cabling trough(1U)
KVMS (1U)
Subrack 0(14U)
Filler panel(3U)
Filler panel(3U)
Filler panel(3U)
1-4

Issue 01 (2009-02-10)

System Principle
Figure 1-3 shows the physical structure and connections of the MSOFTX3000.
Figure 1-3 Physical structure of the MSOFTX3000
1#
Service processing
subsystem
SS
WW
UU
SS
WW
I I
S
M
M
S
M
M
0#
2# - 3#
UUUUSSUU
P P P P WW P P
BBBBUUBB
S
M
M
UUUUSSUU
S S S S WW S S
I I I I I I I I
SS
WW
UU
S
M
M
S
M
M
SS
WW
I I
S
M
M
Monitoring
center
Billing
center
LAN Switch
Bearer
network
LAN Switch
Local maintenance
terminal
Network
managemen
t center
The MSOFTX3000 consists of the following subsystems:

l
Service processing subsystem
Maintenance management subsystem
Environment monitoring subsystem
The subracks of the MSOFTX3000 are directly connected to each other. The principles for
interconnection between subracks are as follows:
l
All the network cables used for interconnection between subracks are connected to subrack
0#.
Ethernet communication is set up on both the Fabric and Base planes to implement dualplane Ethernet communication.
Table 1-1 presents the network cable connections between subracks.
Issue 01 (2009-02-10)

1-5

System Principle
Table 1-1 Network cable connections between subracks

Boards in
Subrack
0#
Plane of
Subrack
0#
Network
Port in
Subrack
0#
Connectto
Subrack
Connectto Board
Connectto Plane
Connectto
Network
Port
SWI in slot
06
FABRIC
1#
SWI in slot
06
FABRIC
SWI in slot
06
BASE
SWI in slot
06
BASE
SWI in slot
07
FABRIC
SWI in slot
07
FABRIC
SWI in slot
07
BASE
SWI in slot
07
BASE
SWI in slot
06
FABRIC
SWI in slot
06
FABRIC
SWI in slot
06
BASE
SWI in slot
06
BASE
SWI in slot
07
FABRIC
SWI in slot
07
FABRIC
SWI in slot
07
BASE
SWI in slot
07
BASE
SWI in slot
06
FABRIC
SWI in slot
06
FABRIC
SWI in slot
06
BASE
SWI in slot
06
BASE
SWI in slot
07
FABRIC
SWI in slot
07
FABRIC
SWI in slot
07
BASE
SWI in slot
07
BASE
2#
3#
1.1.3 Service Processing Subsystem

The service processing subsystem, also known as the host, is the core of the MSOFTX3000. It
comprises service processing subracks and service processing boards. It fulfills functions such
as service processing and resource management.
Inter-Device Communication
The communication of service processing subsystem consists of three parts:
l
1-6
Communication between subracks: The subracks communicate with each other through the
network connections between the WSMUs in the basic subrack and the extended subracks.

Issue 01 (2009-02-10)

System Principle
The communication is carried out through dual planes, namely, the Fabric and the Base
planes.
l
Communication between the host and the external equipment: The host communicates with
the external equipment through IP, TDM, and ATM interfaces. (MSOFTX3000V2R8C1
provides only the IP interface.)
Communication between the host and the OMU: The OMU, iGWB, and XPTU modules
are deployed on the boards in the configuration cabinet. They communicate with the host
through the internal bus.
System Capacity
The system capacity depends on the number of configured service processing subracks.
Depending on the actual conditions, one or two service processing subracks can be configured.
This can fully meet the requirements for smooth expansion.
1.1.4 Maintenance Management Subsystem

The maintenance management subsystem, also known as the OMU, is composed of the active
and standby OMU boards, active and standby iGWB boards, LMT, and communication devices.
It fulfills functions such as O&M and CDR management.
The communication of the maintenance management subsystem consists of three parts:
l
Communication between the maintenance management subsystem and the host: The OMU
boards and iGWB boards communicate with the host through the internal Base bus.
Communication between the LMT and the OMU and iGWB: The active and standby
OMUs and iGWBs are connected to the LAN switch using network cables. The LMT
communicates with the OMUs and the iGWBs using TCP/IP in client/server mode. The
OMU also provides NM interfaces externally through the LAN switch.
Communication between the OMU and the billing center: The active and the standby
iGWBs respectively provide a GE interface to the billing center.
1.1.5 Environment Monitoring Subsystem

The environment monitoring subsystem is comprised of the fan monitoring module of each
service processing subrack, and the power supply monitoring module and MRMU (optional) of
each cabinet. It is designed to ensure that the MSOFTX3000 operates in a normal environment.
1.2 Logical Structure

The MSOFTX3000 can be viewed as a system comprised of multiple logical subsystems from
the service logic perspective.
1.2.1 General Logical Structure
Logically, the MSOFTX3000 is composed of the service processing subsystem, switching
subsystem, electromechanical subsystem, and equipment management subsystem.
1.2.2 Processor Subsystem
The processor subsystem fulfills the arbitration and service processing functions of the system.
1.2.3 Switching Subsystem
The switching subsystem fulfills the data exchange function in the system.
Issue 01 (2009-02-10)

1-7

System Principle
1.2.4 Electromechanical Subsystem

The electromechanical subsystem fulfills the power supply function of the system.
1.2.5 Equipment Management Subsystem
The equipment subsystem is comprised of the shelf management modules (SMMs), subrack data
modules (SDMs), and baseboard management controllers (BMCs) on various blade server
boards and modules. It fulfills functions such as status monitoring, management, and
maintenance of the hardware and management of alarms and statistics.
1.2.1 General Logical Structure

Logically, the MSOFTX3000 is composed of the service processing subsystem, switching
subsystem, electromechanical subsystem, and equipment management subsystem.
As shown in Figure 1-4, the switching subsystem acts as the pivot and the processor subsystem
acts as the core. They, together with the electromechanical subsystem and equipment
management subsystem, constitute a powerful service processing platform.
Figure 1-4 Logical structure of the MSOFTX3000
Equipment management
subsystem
Switching
subsystem
SWU/SWI
Electromechanical
subsystem
SMM/SDM
SWU/SWI
FAN
SMM/SDM
FAN
PEM
PEM
Backplane
IPMB
UPB/
USI
UPB/
USI
UPB/
USI
UPB/
USI
Service processing
subsystem
UPB/
USI
UPB/
USI
BASE
Fabric
NOTE
SPM: The service processing module (SPM) is comprised of the UPB (front board) and the USI (back
board).
1.2.2 Processor Subsystem

The processor subsystem fulfills the arbitration and service processing functions of the system.
The processor subsystem is comprised of blade server boards, that is, UPBs. Designed with highperformance and multi-core processors, the blade server boards can deliver powerful processing
capability. In addition, they can provide abundant service interfaces through the mapping rear
interface boards. The blade server boards can be installed with different software to function as
the service processing boards as well as the OMU and the iGWB.
1-8

Issue 01 (2009-02-10)

System Principle
1.2.3 Switching Subsystem

The switching subsystem fulfills the data exchange function in the system.
The switching subsystem is comprised of the the switching units (SWUs, front boards) and
switching interface units (SWIs, back boards), which are compliant with PCI Industrial
Computers Manufacturers Group (PICMG) 3.0 and 3.1 specifications. Designed with a dualstar structure, the switching subsystem fulfills functions such as system control and data
exchange and interconnection at the service plane.
1.2.4 Electromechanical Subsystem

The electromechanical subsystem fulfills the power supply function of the system.
The electromechanical subsystem is comprised of the power distribution module, fan control
module, and system backplane. The power distribution module provides redundant backup
power supplies and power filters for the system. The fan control module monitors and controls
the temperature of the equipment. The backplane provides power inputs and signal
interconnection for various boards in the subrack.
1.2.5 Equipment Management Subsystem

The equipment subsystem is comprised of the shelf management modules (SMMs), subrack data
modules (SDMs), and baseboard management controllers (BMCs) on various blade server
boards and modules. It fulfills functions such as status monitoring, management, and
maintenance of the hardware and management of alarms and statistics.
1.3 System Bus Structure

The system buses connect various subsystems of the MSOFTX3000. The subsystems exchange
information and communicate with each other through the system buses.
As shown in Figure 1-5, the MSOFTX3000 consists of the following types of buses:
l
IPMB bus
Base bus
Fabric bus
Issue 01 (2009-02-10)

1-9

System Principle
Figure 1-5 System bus structure of the MSOFTX3000

Serial
IPMB
BASE
FABRIC
TDM
PDB
S
W
I
S
W
I
S
D
M
S
D
M
S
W
U
S
W
U
S
M
M
S
M
M
F
A
N
F
A
N
P
E
M
P
E
M
IPMB
BASE
FABRIC
TDM
U
P
B
U
P
B
U
P
B
U
P
B
U
P
B
U
P
B
U
P
B
U
P
B
U
P
B
U
P
B
U
P
B
U
P
B
USI
or
ETI
USI
or
ETI
USI
or
ETI
USI
or
ETI
USI
or
ETI
USI
or
ETI
USI
or
ETI
USI
or
ETI
USI
or
ETI
USI
or
ETI
USI
or
ETI
USI
or
ETI
1.3.1 IPMB Bus

IPMS bus is the equipment management bus of the entire system. It connects all the modules
and boards. The SMM manages the hardware in the subrack through the IPMB bus.
1.3.2 Base Bus
The Base bus is located on the management and control plane of the system. It provides a channel
for software loading, alarm reporting, and maintenance message delivery.
1.3.3 Fabric Bus
The Fabric bus provides a data channel for the system service plane. It transmits the service
information of the system.
1.3.1 IPMB Bus

IPMS bus is the equipment management bus of the entire system. It connects all the modules
and boards. The SMM manages the hardware in the subrack through the IPMB bus.
Function
The SMM is the management module of the OSTA2.0 subrack. It manages all the boards and
modules in the subrack. The IPMB bus is the equipment management bus of the entire system.
Through the IPMB bus, the SMM fulfills functions such as equipment management, event
management, asset management, remote maintenance, configuration restore, energy saving
control, power monitoring, and fan speed adjustment. Figure 1-6 shows the connections of the
IPMB buses.
1-10

Issue 01 (2009-02-10)

System Principle
Figure 1-6 Connections of IPMB buses

PDB
Serial
IPMB
SWI
SWI
SDM
SDM
SWU
SWU
SMM
SMM
FAN
FAN
UPB
UPB
UPB
UPB
UPB
UPB
UPB
UPB
UPB
UPB
UPB
UPB
USI
USI
USI
USI
USI
USI
USI
USI
USI
USI
USI
USI
SPM
SPM
SPM
SPM
SPM
SPM
SPM
SPM
SPM
SPM
SPM
SPM
IPMS bus is the equipment management bus of the entire system, which connects all the modules
and boards. The SMM is the core of the entire management system. It communicates with the
intelligent platform management controller (IPMC) of the board, fan frame, and PDF through
IPMB buses to issue monitoring commands and report messages.
Through the connections between the IPMB buses and the SMM, the system implements the
monitoring and management functions of the field replaceable unit (FRU). The IPMC of the
FRU detects the temperature, voltage and reset of a board, the presence and rotating speed of a
fan, and the voltage and current of the power distribution box. When detecting an error, the
IPMC reports an alarm to the SMM.
Implementation
A dual-star and dual-bus topology is adopted for the IPMB bus. The implementation is as
follows:
l
Each SMM provides 40 IPMB interfaces to connect to the BMCs of various boards and
modules in the subrack.
Each board and module provides two IPMB interfaces to connect to the IPMB buses of the
system so that they can communicate with the SMM.
The two SMMs connect to each other through two IPMB buses for the data synchronization.
Issue 01 (2009-02-10)

1-11

System Principle
1.3.2 Base Bus

The Base bus is located on the management and control plane of the system. It provides a channel
for software loading, alarm reporting, and maintenance message delivery.
Function
The SWU is the switching core of the Base plane. It implements information exchange on the
system control plane and provides external interfaces of the Base plane. All boards connect to
the SWU over the Base plane. The SWU exchanges maintenance messages among all the boards.
Figure 1-7 shows the connections of the Base buses.
Figure 1-7 Connections of the Base buses
BASE
SWI
SWI
SDM
SDM
SWU
SWU
SMM
SMM
UPB
UPB
UPB
UPB
UPB
UPB
UPB
UPB
UPB
UPB
UPB
UPB
USI
USI
USI
USI
USI
USI
USI
USI
USI
USI
USI
USI
SPM
SPM
SPM
SPM
SPM
SPM
SPM
SPM
SPM
SPM
SPM
SPM
Implementation
A dual-star topology is adopted for the Base bus. The implementation is as follows:
l
1-12
Each SWU provides twenty-four 10/100/1000M BASE-T Base interfaces. The planning of
the interfaces is as follows:
12 interfaces: connected to 12 UPBs
2 interfaces: connected to the active and the standby SMMs
1 interface: used to connect the active and the standby SWUs
4 interfaces: used to connect external equipment

Issue 01 (2009-02-10)

System Principle
5 interfaces: reserved
The SMM and each UPB provide two Base interfaces to connect to the dual buses on the
Base plane so that system information can be exchanged through the SWU.
1.3.3 Fabric Bus

The Fabric bus provides a data channel for the system service plane. It transmits the service
information of the system.
Function
The SWU is the switching core of the Fabric plane. It implements information exchange on the
system service plane and provides external interfaces. All UPBs connect to the SWU over the
Fabric plane. They exchange service messages through the SWU. Figure 1-8 shows the
connections of the Fabric buses.
Figure 1-8 Connections of the Fabric buses
Fabric
SWI
SWI
SWU
SWU
UPB
UPB
UPB
UPB
UPB
UPB
UPB
UPB
UPB
UPB
UPB
UPB
USI
USI
USI
USI
USI
USI
USI
USI
USI
USI
USI
USI
SPM
SPM
SPM
SPM
SPM
SPM
SPM
SPM
SPM
SPM
SPM
SPM
Implementation
A dual-star topology is adopted for the Fabric bus. The implementation is as follows:
l
Issue 01 (2009-02-10)
Each SWU provides twenty-four 10/100/1000M BASE-BX Fabric bus interfaces. The
planning of the interfaces is as follows:
1-13

System Principle
12 interfaces: connected to 12 UPBs
1 interface: connected to the other SWU
4 interfaces: used to connect to the external equipment
5 interfaces: reserved
Each UPB provide two Fabric interfaces to connect to the dual buses on the Fabric plane
so that system information can be exchanged through the SWU.
1.4 Software Structure

The MSOFTX3000 adopts the distributed software structure. The software functions are
distributed among the server boards and can be configured flexibly to meet the actual networking
requirements.
1.4.1 Overview of Software Architecture
The MSOFTX3000 software consists of the host software and the OMU software.
1.4.2 Host Software
The host software adopts a layered modular design and consists of the following parts from
bottom to top: operating system, middleware, and application software.
1.4.3 OMU Software
The OMU software consists of the OMU, LMT, WebUI, and iGWB. The OMU is distributed
on boards and the LMT is distributed on workstations. The OMU software fulfills functions such
as man-machine interaction and equipment management.
1.4.1 Overview of Software Architecture

The MSOFTX3000 software consists of the host software and the OMU software.
Figure 1-9 shows the overall software architecture of the MSOFTX3000.
Figure 1-9 Overall software architecture of the MSOFTX3000
Host
software
Service processing
Database
Protocol processing
Signaling bearer
Device
management
Performance
Bill
Alarm
Maintenance
Exchange
Database software
GUI
MML
iGWB
XPTU
Communication
Middleware
Operating system
Communication
Middleware
Operating system
Differentiated by location, the MSOFTX3000 software can be classified into host software and
OMU software.
1-14

Issue 01 (2009-02-10)

System Principle
The host software is distributed on the boards in the service processing subrack. The host
software performs the functions such as communication, signaling transmission, equipment
management, memory database implementation, and load balancing.
The OMU software consists of the OMU, LMT, and WebUI. The OMU is distributed on
boards and the LMT and WebUI are distributed on workstations. The OMU software fulfills
functions such as man-machine interaction and equipment management.
1.4.2 Host Software

The host software adopts a layered modular design and consists of the following parts from
bottom to top: operating system, middleware, and application software.
Operating System
The MSOFTX3000 runs the Linux operating system.
Middleware
The middleware of the MSOFTX3000 is the DOPRA plug-in software platform developed by
Huawei. It adopts the middleware technology to shield the underlying operating system from
the upper-layer application software.
The middleware enhances the software portability among different platforms. The application
software can be used on different hardware platforms with minimal effort. Therefore, the system
can provide the stable software version within a short time.
Application Software
The application software is on the top layer in the software structure of the MSOFTX3000. By
loading different application software, boards can provide different functions and features. The
application software of the MSOFTX3000 can be classified into the following types:
l
Signaling bearer software: The software is distributed on the WBSG and the WIFM. It
fulfills functions such as broadband and narrowband signaling access and lower-layer
protocol processing.
Service processing software: The software is distributed on the WCCU and WMGC. It
fulfills functions such as call signaling processing, mobility management, and resource
management.
Database software: The software is distributed on the WCDB and WVDB. It manages the
data of the MSOFTX3000 and dynamic subscriber data.
System support software: The software is distributed on the SMM and service boards. It
implements system management and equipment communication.
Operation and maintenance software: The software is distributed on the SMM and service
boards. It receives instructions from the OMU and returns the results.
1.4.3 OMU Software

The OMU software consists of the OMU, LMT, WebUI, and iGWB. The OMU is distributed
on boards and the LMT is distributed on workstations. The OMU software fulfills functions such
as man-machine interaction and equipment management.
The OMU software is classified into the following types:
Issue 01 (2009-02-10)

1-15

System Principle
l
OMU: The OMU software is the core of the operation, administration, and maintenance
system. You can log in to the OMU through the LMT to maintain the equipment and manage
user rights.
LMT: The LMT, also known as the client software, incorporates different service consoles.
You can manage data, equipment, and alarms through the LMT.
WebUI: The WebUI software, that is, the WEB client, enables you to perform performance
management and system upgrade through the WEB browser (Internet Explorer).
1.5 System Process

The system processes of the MSOFTX3000 can be classified into host process and OMU process.
1.5.1 Host Process
The host processes of the MSOFTX3000 consist of the following: MON, IMU, SRMU, SMU,
and service processes.
1.5.2 Background Process
The background processes of the MSOFTX3000 consist of the following: O&M access process,
service processing process, equipment access process, and resource monitoring process.
1.5.1 Host Process

The host processes of the MSOFTX3000 consist of the following: MON, IMU, SRMU, SMU,
and service processes.
Figure 1-10 shows the deployment of the host processes.
Figure 1-10 Deployment of the host processes
Service processing board
SRMU
SMM
SMU
SMU
MON
MON
SRMU
VCU100
GCU100
SMM
VCU100
GCU100
1-16
IMU
IMU
IMU
IMU
MON
MON
MON
MON

Issue 01 (2009-02-10)

System Principle
MON process (monitoring process): Each board runs one MON process. If a certain process
on the board exits, the MON process starts the process automatically. In addition, the MON
process detects the status of the other processes on the same board using heartbeat signals.
If the MON process determines that a process is abnormal, then it restarts the process too.
IMU process (board management process): Each service processing board runs an IMU
process. The IMU process manages the board hardware resources. For example, the IMU
process periodically checks the temperature and voltage of the CPU, status of the network
port, and time of the board.
SRMU process (subrack management process): Each subrack runs two SRMU processes.
The two processes are deployed on the boards where the active and the standby GCU100
process groups reside. The SRMU arbitrates the status of the processes in the same subrack
and reports the status of the processes to the SRMU processes in other subrack and the IMU
process in the same subrack.
SMU process (system management process): One SMM runs an SMU process. The SMU
processes work in active/standby mode. They manage the status of the hardware in the
subrack and arbitrate the active/standby status of the SRMU processes in the same subrack.
Service process: The service process, also known as service module, processes specific
services. The system has six types of service modules. They are WCCU, WVDB, WBSG,
WIFM, WCDB, and WMGC. These processes are deployed on service processing boards
in three combination modes.
GCU100 process group: The GCU100 process group runs on the UPB. The
configuration of a GCU100 process group is as follows: 8CCU+2VDB+2BSG+1CDB
+1IFM+1MGC.
GCU101 process group: The GCU101 process group runs on the UPB. The
configuration of a GCU101 process group is as follows: 8CCU+2BSG+1CDB+1IFM
+1MGC.
VCU100 process group: The VCU100 process group runs on the UPB. The
configuration of a VCU100 process group is as follows: 10CCU+3VDB+3BSG.
TCU100 process group: The TCU100 process group runs on the UPB. The configuration
of a VCU100 process group is as follows: 12CCU+2BSG.
1.5.2 Background Process

The background processes of the MSOFTX3000 consist of the following: O&M access process,
service processing process, equipment access process, and resource monitoring process.
Each module incorporates multiple background processes to implement the functions of a certain
management function domain. Figure 1-11 shows the logical view of the background processes.
Issue 01 (2009-02-10)

1-17

System Principle
Figure 1-11 Logical view of the background processes

Active OMU
OMU Monitor
Resource
monitoring
process
Monitor the
status of the
Mirror process Dual-OMU
cluster heartbeat
Active Mirror
Standby OMU
OMU Monitor
Monitor the
status of the
Mirror process
Standby Mirror
Monitor the service status
O&M
access
process
1-18
Service
processing
process
Equipment
access
process
Resource monitoring process: The resource monitoring processes monitor the status of the
system service processes. This type of process consists of the OMUMonitor process and
the Mirror process. The OMUMonitor process monitors the Mirror process while the Mirror
process monitors the service processes except the OMUMonitor process. When the
OMUMonitor process detects that the Mirror process exits, it starts the Mirror process
automatically. When the Mirror process detects that a certain background process exits, it
restarts the process automatically. In addition, in the dual-node configuration, the Mirror
process provides the dual-node status arbitration and switchover functions.
O&M access process: The O&M access processes provide various O&M interfaces to help
you maintain the system. They receive the messages sent from the upper-layer management
system and service processing processes, converts the format of the messages, and delivers
the messages. This type of process consists of MML, LMT-SRV, SOAP-AGT, and SNMPAGT. They fulfill functions such as command parsing, command delivery, message
generation, operation authentication, and operation log.
Equipment access process: The equipment access processes provide various equipment
access interfaces to help you maintain multiple types of equipment. They receive the
messages sent from the service processing processes and the host, converts the format of
the messages, and delivers the messages. This type of processes consists of the SNMPMGR (SNMP Management) process and binary interface process. They provide the SNMP
interface and binary interface between NEs.
Service processing process: The service processing processes manage the

telecommunications network. They receive the messages from the O&M access processes
and equipment access processes. They fulfill functions such as configuration management,
alarm management, maintenance, performance management, security management,
inventory management, monitoring management, backup management, report
management, and resource management.
Issue 01 (2009-02-10)

System Principle
2 Service Processing Subsystem
Service Processing Subsystem
About This Chapter

This topic describes the service processing subsystem. The service processing subsystem is the
core of the MSOFTX3000. It implements functions with the assistance of the operation and
maintenance management subsystem and the environment monitoring subsystem.
2.1 Processing of Signaling over IP
This topic describes the processing of signaling over IP.
Issue 01 (2009-02-10)

2-1

System Principle
2.1 Processing of Signaling over IP

This topic describes the processing of signaling over IP.
The MSOFTX3000 supports following types of signaling over IP:
l
SS7 signaling over M2UA, including TUP, ISUP, SCCP, and upper-layer user protocols
SS7 signaling over M3UA
BICC signaling over SCTP
SIP signaling over UDP
H.248 signaling over SCTP
2.1.1 Processing of Signaling over M2UA

This topic describes the uplink processing path and the downlink processing path of signaling
over M2UA.
over M3UA.
2.1.3 Processing of Signaling over BICC
over BICC.
2.1.4 Processing of Signaling over SIP
over SIP.
2.1.5 Processing of Signaling over H.248
over H.248.

over M2UA.
Figure 2-1 shows the processing paths of signaling over M2UA in the MSOFTX3000.
2-2

Issue 01 (2009-02-10)

System Principle
Figure 2-1 Uplink processing path of signaling over M2UA

Fabric 1
Fabric 2
SWI
SWI
SWI
SWI
SWU
SWU
SWU
SWU
Fabric 1
Fabric 1
Fabric 2
Fabric 2
UPB
UPB
UPB
UPB
UPB
UPB
I M C
F G D
M C B
I M C
F G D
M C B
B V C
S D C
G B U
B V C
S D C
G B U
B V C
S D C
G B U
B V C
S D C
G B U
USI
USI
Uplink Processing Path

1.
The USI board receives IP packets through the external IP interface, performs physical
layer processing of the messages, and transfers the packets to the IFM process through a
fixed connection.
2.
After MAC layer processing of the messages, the IFM process, based on the IP protocol
type, local IP address, local SCTP port number, peer IP address, and peer SCTP port
number, transfers the messages to the designated BSG process through the Ethernet
switching plane, i.e. the Fabric plane, for further processing. This process is called level-1
message dispatch or bearer signaling message dispatch.
NOTE
You need to configure the mapping between BSG process and the combination of IP protocol type,
local IP address, local SCTP port number, peer IP address, and peer SCTP port number.
3.
After IP, SCTP, M2UA, and MTP3 layer processing of the messages, the BSG process
transfers the messages to the upper-layer dispatch modules, namely, TUP/ISUP and SCCP,
for level-2 message dispatch.
4.
The TUP/ISUP dispatch module, based on the NI, OPC, DPC, and CIC, transfers the
messages through the Ethernet switching plane to the CCU process that is responsible for
processing the CIC. The SCCP dispatch module transfers the messages to the CCU process
that is responsible for processing the session based on the TCAP session ID or to the CCU
process with the least load.
5.
The CCU process performs user layer processing of the messages.
Issue 01 (2009-02-10)

2-3

System Principle
Downlink Processing Path

1.
The CCU process, based on the module number of the BSG associated with M2UA and
MTP3 links, transfers the received messages through the Ethernet switching plane to the
corresponding BSG process.
2.
After M2UA and MTP3 layer processing of the messages, the BSG process, based on the
source IP address of the IP packets, transfers the messages to the designated IFM process
through the Ethernet switching plane.
3.
After MAC layer processing of the messages, the IFM process transfers the IP messages
to the USI board through a fixed connection.
4.
The USI board processes the IP messages, and sends them out of the MSOFTX3000 through
the network cable.

over M3UA.
Figure 2-2 shows the processing paths of signaling over M3UA in the MSOFTX3000.
Figure 2-2 Uplink processing path of signaling over M3UA
Fabric 1
Fabric 2
2-4
SWI
SWI
SWI
SWI
SWU
SWU
SWU
SWU
Fabric 1
Fabric 1
Fabric 2
Fabric 2
UPB
UPB
UPB
UPB
UPB
UPB
I M C
F G D
M C B
I M C
F G D
M C B
B V C
S D C
G B U
B V C
S D C
G B U
B V C
S D C
G B U
B V C
S D C
G B U
USI
USI

Issue 01 (2009-02-10)

System Principle

1.
fixed connection.
2.
3.
After IP, SCTP, and M3UA layer processing, the BSG process adapts the M3UA layer to
the MTP3 layer (with the embedded SG feature), and transfers the messages to the upperlayer dispatch modules, namely, TUP/ISUP and SCCP.
NOTE
The adaptation of M3UA to MTP3 shields M3UA for the upper layers so that the upper layers interact
only with the MTP3 layer.
4.
The TUP/ISUP dispatch module, based on the NI, OPC, DPC, and CIC, transfers the
messages through the Ethernet switching plane to the CCU process that is responsible for
processing the CIC. The SCCP dispatch module transfers the messages to the CCU process
that is responsible for processing the session based on the TCAP session ID or to the CCU
process with the least load.
5.

1.
The CCU process, based on the module number of the BSG associated with M2UA and
MTP3 links, transfers the received messages through the Ethernet switching plane to the
corresponding BSG process.
2.
After M3UA layer processing of the messages, the BSG process, based on the source IP
address of the IP packets, transfers the messages to the designated IFM process through
the Ethernet switching plane.
3.
to the USI board through a fixed connection.
4.
the network cable.
2.1.3 Processing of Signaling over BICC

over BICC.
The BICC protocol is used on the Nc interface. Figure 2-3 shows the processing paths of
signaling over BICC in the MSOFTX3000.
Issue 01 (2009-02-10)

2-5

System Principle
Figure 2-3 Uplink processing path of signaling over BICC

Fabric 1
Fabric 2
SWI
SWI
SWI
SWI
SWU
SWU
SWU
SWU
Fabric 1
Fabric 1
Fabric 2
Fabric 2
UPB
UPB
UPB
UPB
UPB
UPB
I M C
F G D
M C B
I M C
F G D
M C B
B V C
S D C
G B U
B V C
S D C
G B U
B V C
S D C
G B U
B V C
S D C
G B U
USI
USI

1.
The USI board receives IP messages through the external IP interface, performs physical
layer processing of the messages, and transfers the messages to the IFM process through a
fixed connection.
2.
3.
After the IP and SCTP layer processing of the messages, the BSG process, based on the
office direction of the SCTP link and the CIC in the messages, forwards the messages to
the corresponding CCU process through the BICC agent module. The CCU can reside in
the same subrack as the BSG or in a different subrack, depending on the data configuration.
4.
2-6
1.
The CCU process determines the office direction and generates BICC messages. The CCU
process then selects an active SCTP link with the least load, and sends the messages through
the Ethernet switching plane to the BSG process associated with the SCTP link for further
processing.
2.
The BSG process, based on the source IP address of the IP packets, transfers the messages
to the designated IFM process through the Ethernet switching plane.
Issue 01 (2009-02-10)

System Principle
3.
to the USI through a fixed connection.
4.
the network cable.
2.1.4 Processing of Signaling over SIP

over SIP.
The SIP protocol is used on the UDP port. Figure 2-4 shows the processing paths of signaling
over SIP in the MSOFTX3000.
Figure 2-4 Uplink processing path of signaling over SIP
Fabric 1
Fabric 2
SWI
SWI
SWI
SWI
SWU
SWU
SWU
SWU
Fabric 1
Fabric 1
Fabric 2
Fabric 2
UPB
UPB
UPB
UPB
UPB
UPB
I M C
F G D
M C B
I M C
F G D
M C B
B V C
S D C
G B U
B V C
S D C
G B U
B V C
S D C
G B U
B V C
S D C
G B U
USI
USI

1.
fixed connection.
2.
After MAC layer processing of the messages, the IFM process transfers the messages
through the Ethernet switching plane, i.e. the Fabric plane, to the corresponding BSG
process for further processing. For the request messages, the IFM process selects the BSG
process with the SIP processing capability and the least CPU usage. For the response
messages, the the IFM process selects the BSG process based on the extended parameter
Issue 01 (2009-02-10)

2-7

System Principle
in the VIA header. This process is called level-1 message dispatch or bearer signaling
message dispatch.
3.
After processing the IP messages, the BSG process transfers the messages to the CCU
process. For the initial request messages, the BSG process transfers the messages to the
CCU process with the least load. For other messages, the BSG process transfers the
messages to the same CCU process as the initial request messages. This process is called
level-2 message dispatch.
4.
The CCU process performs connectin control of the IP messages.

1.
The CCU process generates SIP messages. For the response messages, the CCU process
transfers the messages to the BSG process that reports the corresponding request messages.
For other messages, the process transfers the messages to the BSG process with the SIP
processing capability and the least CPU usage.
2.
After coding the SIP messages, the BSG process, based on the source IP address of the IP
packets, transfers the messages through the Ethernet switching plane to the target IFM
process for further processing.
3.
4.
the network cable.
2.1.5 Processing of Signaling over H.248

over H.248.
The H.248 protocol is used on the Mc interface. Figure 2-5 shows the processing paths of
signaling over BICC in the MSOFTX3000.
2-8

Issue 01 (2009-02-10)

System Principle
Figure 2-5 Uplink processing path of signaling over H.248

Fabric 1
Fabric 2
SWI
SWI
SWI
SWI
SWU
SWU
SWU
SWU
Fabric 1
Fabric 1
Fabric 2
Fabric 2
UPB
UPB
UPB
UPB
UPB
UPB
I M C
F G D
M C B
I M C
F G D
M C B
B V C
S D C
G B U
B V C
S D C
G B U
B V C
S D C
G B U
B V C
S D C
G B U
USI
USI

1.
fixed connection.
2.
switching plane for further processing.
3.
After IP and SCTP layer processing of the messages, the BSG process transfers the
messages to the H.248 dispatch module.
4.
The H.248 dispatch module decodes the H.248 messages and transfers the messages to the
CCU or MGC process.
5.
The uplink H.248 messages consists of ServiceChange message, Notify messages, and
response messages. For the ServiceChange messages (used for MGW registration, link
status maintenance, and TDM termination status maintenance), the BSG process transfers
the messages to the designated MGC process based on the MGC module number (the
number should be configured manually). For the Notify messages (used for reporting H.
248 events), the BSG process transfers the messages to the MGC or CCU process,
depending on the type of the H.248 event. For the H.248 events irrelevant to calls or with
all-zero or all-F Request ID, the BSG process transfers the messages to the MGC process.
For other H.248 events, the BSG process transfers the messages to the CCU process. For
the response messages, the BSG process transfers the messages to the MGC or CCU process
based on the Transaction ID in the H.248 messages. The Transaction ID in the H.248
Issue 01 (2009-02-10)

2-9

System Principle
messages is allocated by the MGC or CCU process when reporting request messages. It
contains the module number of the MGC or the CCU process. Therefore, the BSG process
can obtain the corresponding module number through the Transaction ID carried in the
response messages.
2-10
1.
The CCU or the MGC selects an appropriate SCTP link, and sends the H.248 messages to
the BSG module associated with the SCTP link. The CCU process initiates connection
control messages while the MGC process initiates MGW management and resource
management messages.
2.
After the H.248 dispatch module of the BSG process decodes the H.248 messages, the BSG
process, based on the source IP address of the IP packets, transfers the messages through
the Ethernet switching plane to the target IFM process for further processing.
3.
4.
the network cable.

Issue 01 (2009-02-10)

System Principle
3 Maintenance Management Subsystem
Maintenance Management Subsystem
About This Chapter

This chapter describes the maintenance and management subsystem in the MSOFTX3000.
3.1 Hardware Architecture
This section describes the hardware architecture of the maintenance and management subsystem.
3.2 Software Architecture
This topic describes the software architecture of the maintenance and management subsystem.
The maintenance and management subsystem consists of the following software components:
LMT software and OMU software, NMS software, and iGWB software.
3.3 Security Management
This section describes the security management functions of the MSOFTX3000.
3.4 Data Management
This section describes how to manage data in the MSOFTX3000, namely, how to store and
operate data. In terms of data storage, both OMU data and host data are involved.
3.5 Loading Data
This section describes how to load software and data from an external memory to the memory
of the board in the MSOFTX3000.
3.6 Software Patch Management
This section describes how to manage software patches.
Issue 01 (2009-02-10)

3-1

System Principle
3.1 Hardware Architecture

This section describes the hardware architecture of the maintenance and management subsystem.
The maintenance management subsystem consists of the following hardware components:
l
OMU
iGWB
LMT
Figure 3-1 shows the hardware architecture of the maintenance management subsystem.
Figure 3-1 Hardware architecture of the maintenance management subsystem
SWU
SWU
U
P
B
SWU
U
P
B
O
M
U
USI
IPMB plane
SWU
O
M
U
i
G
W
B
i
G
W
B
USI
USI
USI
To the
billing
center
Base plane
Farbic plane
The MSOFTX3000 transmits maintenance and device management messages through the Base
plane (also called the management communication plane).
The management communication plane is used to transmit maintenance, backup, and device
management messages. Take the message flows between the OMU and a service processing
board for example.
The message flow from the OMU to the service processing board is as follows:
3-2

Issue 01 (2009-02-10)

System Principle
1.
A maintenance engineer issues a management message through the LMT.
2.
The LMT sends this message to the OMU through the GE interface on the LAN switch.
3.
The OMU forwards this message to the service processing board through the intra- or intersubrack Base plane.
The message flow from the service processing board to the OMU is as follows:
1.
The service processing board sends a management message to the OMU through the Base
plane.
2.
The OMU processes this message, and then sends it to the LAN switch through the GE
interface.
3.
The LAN switch forwards this message to the LMT and NMS.
3.1.1 OMU
This section describes the functions of the OMU.
3.1.2 iGWB
This topic describes the functions and specifications of the iGWB.
3.1.3 Local Maintenance Terminal (LMT)
This section describes the functions of the LMT.
3.1.1 OMU
This section describes the functions of the OMU.
The Operation & Maintenance Unit (OMU) is a server board designed for operation and
maintenance purposes. It serves as a bridge between the MSOFTX3000 and the LMT. Upon
receiving an operation and maintenance command from a local or remote LMT, the OMU sends
this command to the MSOFTX3000, Then, the MSOFTX3000 returns a response to the LMT.
In addition, the OMU stores and transfers alarm information and performance measurement
information.
NOTE
The OMU is a back administration module, whereas the host is a front administration module. In this
document, the host refers to the MSOFTX3000.
The OMU is installed on the UPB. It runs with the Linux operating system and the DB2 database.
3.1.2 iGWB
This topic describes the functions and specifications of the iGWB.
The iGWB is in active/standby mode. The functions and specifications of the iGWB are as
follows:
l
The iGWB is a board seated in the basic subrack. If several pairs of iGWBs are present,
plan the boards according to the actual requirements.
The iGWB, located between the MSOFTX3000 and the billing center, provides the
following functions: receiving CDRs, preprocessing CDRs, storing CDRs, and serving as
a billing interface.
The iGWB communicates with the CCU through the internal communication system of the
ATCA by using the Huawei sliding window protocol. The iGWB communicates with the
billing center through the WAN/LAN by using the FTP/FTAM.
Issue 01 (2009-02-10)

3-3

System Principle

l
The iGWB is equipped with the Windows Server 2003 operating system.
In standard configuration, each pair of the iGWBs can process up to 3000 CDRs per second,
and store original and final CDRs for at least 7 days.
For more information, refer to the HUAWEI iGateway Bill User Manual.
3.1.3 Local Maintenance Terminal (LMT)

This section describes the functions of the LMT.
The LMT provides the following functions:
l
Data configuration
Device status monitoring
Maintenance
The LMT runs Windows XP operating system. It can be connected to the OMU through a web
browser for performance management purposes.
3.2 Software Architecture

This topic describes the software architecture of the maintenance and management subsystem.
The maintenance and management subsystem consists of the following software components:
LMT software and OMU software, NMS software, and iGWB software.
Figure 3-2 shows the software architecture of the MSOFTX3000 maintenance and management
subsystem.
Figure 3-2 Software architecture
Element management
system
NMS software
Local Maintenance
Terminal
Host
software
OMU software
EMS software
iGWB software
Billing center
iGWB
Maintenance management subsystem
3-4

Issue 01 (2009-02-10)

System Principle
NOTE
For details on the working principles of the iGWB software, refer to the HUAWEI iGateway Bill User
Manual.
For details on the working principles of the EMS software, refer to the appropriate user manual.
The OMU and iGWB communicate with the host for operation and maintenance, and CDR
management.
The OMU software communicates with the EMS software by using the Man Machine
Language (MML), Simple Object Access Protocol (SOAP), Simple Network Management
Protocol (SNMP) for unified maintenance and management of the MSOFTX3000. The
NMS provides an access interface to connect the upper-layer network management system.
The OMU communicates with the LMT through an Ethernet interface by using the TCP/
IP.
3.2.1 OMU Software

This section describes the functions, networking mode, components, and features of the OMU
software.
3.2.2 LMT Software
This section describes the functions of the LMT software.
3.2.1 OMU Software

This section describes the functions, networking mode, components, and features of the OMU
software.
The MSOFTX3000 provides a set of effective O&M options and tools to ensure service
continuity, slash operating costs, and improve QoS. The OMU software is primarily used for
management and maintenance purposes. For instance, the OMU software can be used to manage
system data, performance management data (also called traffic statistics), and alarm information.
Networking Mode
The OMU, the center of the LMT, functions as the server using TCP/IP. On the one hand, the
OMU responds to connection requests sent from the LMT for connection setup purposes by
analyzing and processing commands. On the other hand, the OMU responds to connection
requests sent from the devices for connection setup purposes by processing data loading requests
and alarm information. Figure 3-3 shows the networking mode of the OMU.
Issue 01 (2009-02-10)

3-5

System Principle
Figure 3-3 Networking mode of the OMU
Local maintenance terminal
LAN switch
Floating IP address (Base plane)
Active OMU
Heartbeat
Standby OMU
Floating IP address (Base plane)
Host process
NOTE
If the active and standby OMUs use individual IP addresses, it is inconvenient for active/standby
switchover. To address this problem, a floating IP address is assigned for the active and standby OMUs to
communicate with an external device.
Components
Figure 3-4 shows the components of the OMU software.
3-6

Issue 01 (2009-02-10)

System Principle
Figure 3-4 Components of the OMU software

LEM
LMT
Service layer
GUI operation
Device
access
North access
Service
DCM
CM
SNMP-AGT
Navigation tree
LOAD
FM
LMT-SRV
MML commands
DEBLOG
MML-SRV
Alarm information
MM
SOAP
Device management
SNMP-MGR
PM
Tracer
TM
Task wizard
RMM
RSM
Service layer
Communication layer
LMT architecture
The OMU software consists of the following components:

l
Configuration Management (CM): The CM is primarily used for data conversion. It

converts the data in the OMU database into binary data, and then sends binary data to the
host based on online settings.
Fault Management (FM): The system reports events, faults, and fault recoveries to the OMU
or EMS. The FM provides hierarchical fault management for pinpointing and eliminating
faults in time.
Device log (DEVLOG): The DEVLOG reports software running information in text format
to the OMU and LMT. It provides significant information for system maintenance.
Maintenance Management (MM): The MM maintains and detects system running status in
time.
North Interface (NI): The NI is used to access the system through the SOAP, SNMP agent,
MML server, and LMT server.
SNMP Management (SNMP-MGR): The SNMP-MGR is a network protocol management

module on the MSOFTX3000 side. It provides an interface through the SNMP agent.
Performance Management (PM): The PM collects and displays performance measurement

data. It is an important maintenance option.
Device Communication Management (DCM): The DCM manages and monitors

communication links on the MSOFTX3000 side, and exchanges messages between the
OMU and other devices.
Issue 01 (2009-02-10)

3-7

System Principle
LOAD: The LOAD is used to load host programs and data files.
Trace Management (TM): The TM provides an interface for tracing service messages.
Management Information Tree (MIT): The MIT is used to query managed devices, and
subscribe to and release notifications of managed devices.
Real-time Monitor Management (RMM): The RMM is used to monitor and management
tasks, query status information, and send status information to the LMT.
Report Server Management (RSM): The RSM is used to resolve and report performance
reports.
Features
The OMU software provides the following features:
l
High availability
The OMU uses a carrier-class server and a DB2 as a large database system. The active/
standby OMU provides multi-level self-monitoring options to facilitate data backup, data
recovery, and data security.
Client/server (C/S) mode

By integrating the communication server with the database server, the OMU performs
maintenance tasks in C/S mode, supports simultaneous local or remote data configuration,
and ensures ease of operation and maintenance.
User friendly interfaces

The OMU provides the following user friendly interfaces:
The MML command line interface is used for data configuration and O&M purposes
in the CGP system.
Graphical User Interface (GUI) helps visibly manage alarm information, trace messages
over interfaces, and observe running status.
Web User Interface (WebUI) is used to achieve performance management.
Scalability
The OMU provides high scalability through the following ways:
Managing multiple network elements in distributed mode
Providing superior performance
Supporting inter-operation-system or inter-database transplanting
Providing object-specific operations
Supporting various standard interfaces such as SNMP
3.2.2 LMT Software

This section describes the functions of the LMT software.
The O&M software of the MSOFTX3000 can be installed on a local or remote LMT. The LMT
can communicate with the OMU through a WAN/LAN. The LMT and the OMU work in C/S
mode. The LMT, serving as the client, provides a user-oriented O&M interface.
The LMT software provides the following O&M options through MML and GUI:
l
3-8
Service management system

Issue 01 (2009-02-10)

System Principle
l
Alarm management system
Performance management system
Service Management System

The LMT software provides the following GUI-enabled modules:
l
Object navigation tree

Object nodes are listed under the NE node. The object navigation tree is mounted under
the object node. It is present once you log in to the LMT successfully. Other navigation
trees can be invoked by right-clicking the NE node and choosing the corresponding
command on the shortcut menu.
MML navigation tree

The MML navigation tree provides basic command groups that are sorted by attribute. You
can identify the desired MML command by expanding the MML command tree, and then
double-click the MML command to display the command input pane and Help information
pane.
When you type commands and parameters, the LMT automatically issues the commands
for the following purposes:
Data configuration
Alarm management
Subscriber management
Tracing management
Tracing management provides the following functions for fault location and analysis:
connection tracing, signaling tracing, interface tracing, and message interpretation. You
can use them to trace terminals, trunk circuits, signaling links, and interface protocols on
a real-time and dynamic basis in terms of: connection process, status transition, resource
utilization, telephone number information transfer, and message streams. The tracing
information can be stored for future reference.
Monitoring management
Monitoring management can be used to dynamically display the following information:
Board-specific CPU usage
Memory usage
Memory dumping
Memory contents
Process running status of the OMU and the host
Front panel
The front panel provides the following functions:
Device management
Loading status management

NOTE
Device management is commonly used during routine maintenance. Using this function, you need not
directly observe the device, but observe the GUI to know system running status and board running status.
Issue 01 (2009-02-10)

3-9

System Principle
Alarm Management System

The alarm management system provides clear and concise alarms on a real-time basis. You can
query, browse, and manage alarms through the LMT.
An alarm includes the following information:
l
Alarm name
Alarm generation time and fault recovery time
Alarm level
Fault location information
Fault recovery suggestions
Performance Measurement System

Performance measurement (also known as traffic measurement) is used to measure call-specific
services and objects. The performance management system provides the following functions:
l
Showing the running status of the MSOFTX3000, MGW, MS, or PLMN
Providing useful data for telecommunications network planning, design, implementation,

management, and maintenance purposes
3.3 Security Management

This section describes the security management functions of the MSOFTX3000.
To access the MSOFTX3000, users must have privileges. To run MML commands on the
MSOFTX3000, you must have both operator and workstation privileges.
3.3.1 Command Groups
This section describes security management for command groups.
3.3.2 Workstation Management
This section describes security management for workstations.
3.3.3 Account Management
This section describes how to manage accounts.
3.3.4 Login Time
This section describes how to use login time for security management.
3.3.5 Lock Time
This section describes how to use lock time for security management.
3.3.1 Command Groups

This section describes security management for command groups.
A specific privilege must be defined for each command group. A command can belong to one
or multiple command groups. When having been granted the privilege to use a command group,
an operator or workstation can issue any command in this command group.
Default command groups are designed for different network elements. By default, the
MSOFTX3000 provides 11 command groups, numbered from G_1 to G_11. Each command
3-10

Issue 01 (2009-02-10)

System Principle
group has a default command. Users are allowed to create command groups by adding commands
as required.
G_1 defines the administrator privilege for a command group. An administrator is allowed to
run, add, and remove all commands in a command group.
3.3.2 Workstation Management

This section describes security management for workstations.
A workstation is a computer used for operators to issue commands. A user can use the Access
Control List (ACL) function to configure an IP address or a number segment for a workstation
to access the OMU.
3.3.3 Account Management

This section describes how to manage accounts.
On the LMT of the MSOFTX3000, a user name is used to identify a unique operator. A new
account can have the same user name and attributes as those of the deleted account. The
privileges of the deleted account, however, are not transferred to the new account. This can
prevent an invalid account or a deleted account from logging in to the system.
The password of an account is encrypted, and then stored in the database. To prevent the
password against malicious attacks, the security mechanism of the database is integrated with
the encryption algorithm on the MSOFTX3000.
3.3.4 Login Time

This section describes how to use login time for security management.
On the MSOFTX3000, the OMU allows an operator to log in to the system during a specified
period of time. When logging in to the system within the specified period of time, the operator
is allowed to run authorized commands in a command group.
3.3.5 Lock Time

This section describes how to use lock time for security management.
If a user does not perform any operation within a specified period of time, the user is
automatically locked out of the system. To relog in to the system, the user need to retype the
password to unlock the system. This can prevent unwanted or unauthorized operations, and
further ensures enforcement of assigned policies and system security.
You can configure the lock time on the LMT. The default value is three minutes.
3.4 Data Management

This section describes how to manage data in the MSOFTX3000, namely, how to store and
operate data. In terms of data storage, both OMU data and host data are involved.
3.4.1 Storing OMU Data
OMU data is stored in the DB2. The security management module of the OMU enables operators
to define access control levels for storing OMU data.
3.4.2 Storing Host Data
Issue 01 (2009-02-10)

3-11

System Principle
Host data is stored in the disk.

3.4.3 Operating Data
This topic describes how to operate data.
3.4.1 Storing OMU Data

OMU data is stored in the DB2. The security management module of the OMU enables operators
to define access control levels for storing OMU data.
OMU data is automatically backed up at a preset time. Before modifying any vital data, you
must manually back it up.
3.4.2 Storing Host Data

Host data is stored in the disk.
After successfully loading data, a software management module automatically backs up the data
to the disk of the board.
When the OMU performs data operations, the data management module associated with the
active and standby processes concurrently updates the memory database and backs up static data
to the flash memory of the boards to which the active and standby processes belong.
3.4.3 Operating Data

This topic describes how to operate data.
If you have operated data on a workstation, the system performs the following steps: The services
such as the MML service on the OMU analyze the commands. The configuration management
service stores the modified data in the database of the OMU and converts the data. The DCM
service on the OMU sends the converted data to the data management system of the host. The
data management system updates the data on each service module for security purposes. The
name of a data file sent to the host contains DB_?.DAT, in which the question mark (?) denotes
a module number. Data files vary depending on service processing modules.
Converting Data Format

The OMU converts the data suitable for the LMT into that suitable for service processing
modules. You can convert all or part of the data as required. Only converted data, however, can
be loaded to service processing modules. Data format conversion needs to be performed in the
following scenarios:
l
A new data file is forcibly regenerated.
When you add, remove, or modify any data, the data management console automatically
runs the FMT command to update the data file.
When receiving the FMT command from the traffic statistics console, the OMU converts
the data, and then writes the converted data to the data file in the appropriate module.
Configuring Data
When you configure data, the OMU sends the converted data to the appropriate module in the
host.
After the data in the OMU is modified, you need to configure the data. When to configure the
data depends on whether the OMU is connected to the host and whether the format conversion
3-12

Issue 01 (2009-02-10)

System Principle
function is enabled. When the OMU is connected to the host, the data in the OMU is
automatically configured immediately after being modified. When the OMU is disconnected
from the host, the data in the OMU is not automatically configured immediately after being
modified, but after the OMU is reconnected to the host. Data configuration is performed in the
following scenarios:
l
After you run an ADD, RMV, or MOD command, the OMU automatically configure the
data.
A forced operation is performed by issuing the FMT command.
Performing CRC Check

The OMU of the CGP performs the Cyclic Redundancy Check (CRC) to check data consistency
between the OMU and the host.
The OMU provides the MML command for CRC and periodically sends CRC requests to the
host for table-based data consistency check. When finding any inconsistent data, the OMU
proactively sends a data setting request to the host. If this data inconsistency problem cannot be
eliminated within preset times, the OMU automatically generates an alarm. To address this
problem, you need to configure or load data to ensure data consistency.
Backing Up Data
To ensure data security, the system backs up the OMU and configuration files to a specified
directory. If the system experiences a fault, you can restore the data based on the database and
configuration files. You can choose one of the following methods to back up data:
l
Automatic backup
You can back up data during off-peak hours. When processing this backup command, the
system does not accept any service command request.
Manual backup
You can manually back up data by running an MML command or using the database
management tool.
Performing Automatic Data Format Conversion During OMU Reboot

When the OMU is powered off exceptionally because the power supply becomes faulty, data
conversion or data formation may be unfinished. When the OMU is rebooted, the system checks
for unfinished tasks. If any unfinished task is identified, the system automatically resumes the
task.
Restoring Data
To ensure data security and system maintainability, the MSOFTX3000 provides a configuration
rollback function to restore the data.
This function enables you to send critical service data to the host for trial operation so as to check
whether any error is present.
l
If the trial operation is successful and no error is found, you can make these experimental
data take effect immediately.
If any error is found, you can use the configuration rollback function to restore the data to
the original state securely and rapidly.
Issue 01 (2009-02-10)

3-13

System Principle
When you run the ADD, RMV, or MOD command to configure or modify data, the data is
stored in the database first, then sent to the host, and finally validated in the host. If you have
performed an incorrect operation, you need to restore the data settings by restoring the original
database or rerunning the commands one by one. This is inconvenient for bulk operations.
Restoring the original database involves table settings, host reset, and service interruption that
annoys carriers.
To address these problems, the MSOFTX3000 provides the configuration rollback function. By
using this function, you can restore data as follows: 1. Run BGN TRAN to enable the network
element to enter the transaction mode. 2. Run ADD, RMV, or MOD to change data. 3. Run
CMT TRAN to enable the network element to enter the trial operation mode. 4. If any data
needs to be restored, you can run RBK TST to return to the transaction mode and restore the
data. If any added, removed, or modified data needs to be confirmed, you can run CFM TST to
confirm the data. 5. If you need to cancel or stop the trial operation, you can run CNL TST or
STP TST to enable the network element to enter the normal operation mode.
When a user is restoring data settings for a certain network element, the system prevents any
other user from executing any command, such as a configuration or restoration command.
3.5 Loading Data

This section describes how to load software and data from an external memory to the memory
of the board in the MSOFTX3000.
3.5.1 Loading Options
This section describes the options for loading data, depending on file types and storage locations.
3.5.2 Principles for Loading Data
This section describes the principles for loading data from the OMU.
3.5.3 Procedure for Loading Data
This section describes the procedure for loading data from the OMU.
3.5.1 Loading Options

This section describes the options for loading data, depending on file types and storage locations.
Figure 3-5 shows the options for loading data.
Figure 3-5 Options for loading data
Write
Memory
OMU
Load
Read
Local
storage
media
BASE bus
Data bus
Host board
3-14

Issue 01 (2009-02-10)

System Principle
Depending on different storage locations, the system loads data in the following ways:
l
The system loads software and data from the local storage media (for example, hard disk)
of the OMU or INU (INU for the operating system) to the memory of the board. In this
case, all original files to be loaded are stored in the local storage media of the OMU or INU.
The system loads software and data from the local storage media of a board to the memory
of the board. In this case, all original files to be loaded are stored in the local storage media
of the board.
The system loads the following types of files:

l
Operating system file: The system loads operating system files from the local storage media
of a board or a network to the memory.
Host application file: The system loads service applications from the local storage media
of a board to the memory, or downloads service applications to the local storage media and
then to the memory.
3.5.2 Principles for Loading Data

This section describes the principles for loading data from the OMU.
The MSOFTX3000 can load data from either the OMU or the local storage media of a board.
Take the OMU for example. Figure 3-6 shows the connections for loading data.
Figure 3-6 Connections for loading data
Base bus
SWU
Base bus
Host
board
OMU
Base bus
SWU
Base bus
In the host, a board sends a data loading request to the SWU and OMU through two Base planes.
If one Base plane becomes faulty, the remaining Base plane takes over.
Issue 01 (2009-02-10)

3-15

System Principle
3.5.3 Procedure for Loading Data

This section describes the procedure for loading data from the OMU.
Figure 3-7 shows the procedure for loading data.
Figure 3-7 Procedure for loading data
BIOS
LBP
NBP
OS (Linux)
OMU
Starter
Applications and data files
The procedure for loading data is as follows:

1.
When powering on or resetting the subrack, each board automatically runs its own BIOS
application.
2.
Based on the boot option, the BIOS application determines whether to boot the operating
system locally or through the network.
l
3-16
If the BIOS application determines to boot the operating system locally, the operating
system checks whether local boot attempts fail more than three times.
If yes, the operating system is booted through the network and then automatically
restored.
If no, the operating system is loaded from the local storage media and then booted.
If the BIOS application determines to boot the operating system through the network,
the operating system is booted based on the PXE as follows:
The operating system loads a network boot program (NBP) from the OMU, and then
runs it.
This NBP reads the subrack number, slot number, and hardware version through the
hardware interface, and then sends a loading request to the OMU.
Issue 01 (2009-02-10)

System Principle
The OMU reads the configuration data based on the subrack number, slot number,
and hardware version, and then sends the operating system file to the NBP using
TFTP.
Upon receiving the operating system file, the NBP boots the operating system.
3.
After the operating system is booted, a platform management application is automatically

started.
4.
If any local storage media or file is present, this application reports application and data
files in the local storage media to the OMU for CRC purposes.
5.
If no local storage media or file is present, this application reports a null CRC value to the
OMU. Then, the OMU performs CRC for checking file consistency between the local
storage media and the host.
6.
If any inconsistent file is detected, the OMU requests the host to load the file to the local
storage media.
If no local storage media is detected, the OMU requests the host to load the file to the
memory.
When the file is successfully loaded, the operating system runs its applications.
3.6 Software Patch Management

This section describes how to manage software patches.
During system runnings, adaptive or corrective modifications probably need to be made to the
host software. For example, you may need to correct potential defects in the system or add new
functions to meet service requirements. To address these needs, the traditional solution is to stop
and upgrade the host software. This traditional solution not only causes service interruption but
also deteriorates QoS. Now, Huawei provides the latest solution to dynamically upgrade the host
software using patches. This not only avoids service interruption or minimizes the impact on
services, but also improves QoS.
3.6.1 Basic Concepts
This section describes basic concepts related to software patches.
3.6.2 Key Features
This section describes the key features of a software patch.
3.6.3 Architecture
This section describes the architecture of a patch.
3.6.4 Implementation
This topic describes how to install and uninstall a patch, patch states, and patch state transition.
3.6.1 Basic Concepts

This section describes basic concepts related to software patches.
Patch
A patch is an executable program used to fix a problem with or update a host software.
Issue 01 (2009-02-10)

3-17

System Principle
Patch Number
Patches are developed to fix problems identified during system running. These patches are
numbered in time sequence, for example, patch 1# and patch 2#.
Patch Area
The host memory reserves some space for storing patches.
General-Purpose Patch
A general-purpose patch is used to fix a common problem (for example, a bug) in a main version.
Special-Purpose Patch
A special-purpose patch is used to fix a rare problem (for example, multi-vendor interoperability)
in a few offices.
Patch File
A patch file is a update file used to fix a problem in a main version.
Cold Patch
A cold patch is used to fix a defect by adding a new file or overwriting the source file with a
new file. When installing a cold patch, you need to interrupt the service and reboot the system.
Every cold patch can be installed, moved, or queried for repairing or maintenance purposes.
Hot Patch
A hot patch is used to fix a defect by replacing source codes with new codes. When installing a
hot patch, you need not to interrupt any service and restart the system.
3.6.2 Key Features

This section describes the key features of a software patch.
Main Version-Specific
A patch is designed for a specific main version. If a patch is used for main version A, it cannot
be used for main version B. The reverse is true as well.
If the number of patches reach the limit, the main version need to be upgraded. Existing patches
are packaged in new patches to be released.
Service Packs
A service pack comprises one or multiple cold/hot patches specific to a main version. A service
pack need to be formally released by following the version release procedure. Hot patches are
packaged in a service pack, whereas cold patches are packaged in another service pack. Do not
package both hot and cold patches in a service pack.
3-18

Issue 01 (2009-02-10)

System Principle
Ease of Installation
A hot patch is easy to install with several MML commands available for maintenance personnel.
When installing a hot patch, you need not to restart the system.
CAUTION
Patch installation has a direct impact on CPU; therefore, only users who have administrator
privileges are allowed to install patches.
Self-Healing
If the system is restarted when experiencing a fault, the patches will be automatically loaded to
the boards.
3.6.3 Architecture
This section describes the architecture of a patch.
Patch Tool
A patch consists of the following components:
l
Patch tool
OMU patch management module
Host patch management module
A patch tool is used to generate a patch file in offline mode by using one or multiple patches.
OMU Patch Management Module

The OMU patch management module is part of the OMU software. It provides the following
functions:
l
Providing a command interface for maintenance purposes
Maintaining data consistency between the patch configuration/status tables and the host
based on the command information in the host
Transferring patch files to the host
Generating patch reports
Host Patch Management Module

The host patch management module is part of the host software. It provides the following
functions:
l
Processing patch-specific commands and maintaining the interface
Maintaining data consistency between the patch status table and the host based on the
command information
Receiving patch files and transferring patches to the patch area in the host
Issue 01 (2009-02-10)

3-19

System Principle
Writing patch files to the flash memory
Restoring patches after system reboot
Synchronizing patches between the OMU and the host
3.6.4 Implementation
This topic describes how to install and uninstall a patch, patch states, and patch state transition.
l
Installing and uninstalling a patch

To install a hot patch, perform the following steps: Copy a hot patch or service pack from
the LMT to the Upload folder using the FTP. Run LOD PKG to decompress the hot patch
or service pack and copy it to the patch area. You can install or uninstall the patch when
the equipment is running by loading, activating, rolling back, running, removing, or
querying the hot patch or service pack. You can also uninstall a hot patch by running ULOD
PKG.
To install a cold patch, perform the following steps: Copy a service pack from the LMT to
the Upload folder using the FTP. Run LOD PKG to decompress the service pack and copy
it to the patch area. You can install or uninstall the patch by loading, activating, deactivating,
rolling back, or querying the service pack. You can also uninstall a cold patch by running
ULOD PKG.
Patch states
The host software displays the following patch states for hot patches:
Idle: No hot patch is present.
Deactive: The hot patch is installed in the patch area, but not activated. In this case, the
codes cannot be executed.
Active: The hot patch is activated for trial running. In this case, the codes can be
executed.
Running: The hot patch is running. In this case, you cannot roll back the patch, but
remove the patch.
The host software displays the following patch states for cold patches:
Deactive: The host and OMU return to the state before the loading of the cold patch.
Updated: The contents of the cold patch are updated on the OMU.
Active: The contents of the cold patch are updated on the host.
Rollback: The OMU returns to the state before the loading of the cold patch.
Figure 3-8 shows how a hot patch transits from one state to another.
3-20

Issue 01 (2009-02-10)

System Principle
Figure 3-8 State transition of hot patches

System reset
Load
Deactivated
Idle
Remove
Active
Running
Deactive
Remove
Remove
System reset
System reset
Activated
Confirm
System reset
The active state is temporary. If the system is properly running for a short period of time, you
can run CON PATCH to transit the patch from the active state to the running state. If you identify
a defect, you can run DEA PATCH to roll back this patch and transit it from the active state to
the deactive state.
The running state is a steady state. When the system is restarted, only the patches in the running
state are loaded to the system. The patches in the active state are not loaded to the system.
When the system does not require a patch, you can run RMV PATCH to remove it. In this case,
this patch enters the idle state.
Issue 01 (2009-02-10)

3-21

System Principle
4 Environment Monitoring Subsystem
Environment Monitoring Subsystem
About This Chapter

This chapter describes the environment monitoring subsystem. The environment monitoring
subsystem monitors and adjusts the power supply, fan, and equipment room to enable the
MSOFTX3000 to work in a proper environment.
4.1 Power Supply
The power supply is a vital part of the MSOFTX3000. To ensure high reliability, the
MSOFTX3000 provides dual 3-input power supplies. These power supplies are self-monitoring.
A power supply consists of a power input unit and a power distribution unit.
4.2 Monitoring Power Supplies
The MSOFTX3000 provides a power monitoring module to monitor power supplies, report
power status, and generate alarms on a real-time basis. The power monitoring module is housed
in the PDF.
4.3 Monitoring Fan Boxes
The MSOFTX3000 provides integrated service processing subracks with built-in fan boxes. A
fan monitoring module is used to monitor fan status and to increase/decrease rotation speeds
based on temperature readings.
4.4 Monitoring the Environment of a Telecommunications Room
This topic describes how to monitor the environment of a telecommunications room. The PDF
and MRMU are used to monitor the environment of a telecommunications room. Monitoring
the environment of a telecommunications room is an optional function.
Issue 01 (2009-02-10)

4-1

System Principle
4.1 Power Supply

The power supply is a vital part of the MSOFTX3000. To ensure high reliability, the
MSOFTX3000 provides dual 3-input power supplies. These power supplies are self-monitoring.
A power supply consists of a power input unit and a power distribution unit.
4.1.1 Power Input Unit
A power input unit is used to power the MSOFTX3000 cabinet using the Power Distribution
Frame (PDF).
4.1.2 Power Distribution Unit
A power distribution unit is designed to distribute power from the PDF to individual cabinet
components.
4.1.1 Power Input Unit

A power input unit is used to power the MSOFTX3000 cabinet using the Power Distribution
Frame (PDF).
Figure 4-1 shows the power input unit.
Figure 4-1 Power input unit
-48V1 (2)
-48V2
(1)
RTN_A1 RTN_B1
NEG_A1 NEG_B1
RTN_A2 RTN_B2
NEG_A2 NEG_B2
RTN_A3 RTN_B3
NEG_A3 NEG_B3
RTN_A1 RTN_B1
NEG_A1 NEG_B1
RTN_A2 RTN_B2
NEG_A2 NEG_B2
RTN_A3 RTN_B3
NEG_A3 NEG_B3
RTN_A1 RTN_B1
NEG_A1 NEG_B1
RTN_A2 RTN_B2
NEG_A2 NEG_B2
RTN_A3 RTN_B3
NEG_A3 NEG_B3
GND
GND
(3)
(3)
(3)
PGND
(4)
(1) DC distributor
(2) PDF
(3) MSOFTX3000 cabinet
(4) Protection grounding bar
A power input unit consists of a DC distributor, a PDF, and power cables.

The DC power distribution cabinet and its upper-layer DC switchboard are not part of the
MSOFTX3000. The DC power distribution cabinet is required to provide dual 3-input power
supplies with steady-state voltage.
During normal operation, dual power supplies simultaneously provide system power. When one
power supply becomes faulty, the remaining power supply immediately ramps up to provide full
power and maintain uninterrupted power to the system.
4-2

Issue 01 (2009-02-10)

System Principle
4.1.2 Power Distribution Unit

A power distribution unit is designed to distribute power from the PDF to individual cabinet
components.
Electrical Connections
The MSOFTX3000 consists of integrated configuration cabinets and service processing
cabinets. Different cabinets are equipped with different components. Their electrical connections
vary from cabinet to cabinet, as shown in Figure 4-2.
Figure 4-2 Electrical connections
Integrated configuration cabinet
Service processing cabinet
B 10 9 8 7 6 5 4 3 2 1 10 9 8 7 6 5 4 3 2 1 A
RTN(+)
RTN(+)
NEG(-)
NEG(-)
7- 8- 3- 4-19-17-15- 11- 10- 135- 6- 1- 2- 18-16-14- 12-9-
B 10 9 8 7 6 5 4 3 2 1 10 9 8 7 6 5 4 3 2 1 A
RTN(+)
RTN(+)
NEG(-)
NEG(-)
12- 11- 8- 7- 4- 310- 9- 6- 5- 2- 1W1
12+11+8+ 7+ 4+ 3+
10+ 9+6+ 5+ 2+ 1+
W2
5+ 6+1+ 2+19+17+15+12+ 9+
W1
7+ 8+ 3+ 4+19+17+15+11+10+13+
W2
Subrack 2
Subrack 1
1-
1+
+
2-
2+
+
3+
+
4-
1-
4+
+
MRMU
10
W3
LAN switch 1
11
W4
1+
+
2-
2+
+
3--
3+
+
4-
4+
+
W3
Subrack 1
Cabling space
12
W5
LAN switch 0
Cabling space
W6
13
KVMS
W7
5-
Subrack 0
5-
5+
+
6-
6+
+
7+
+
8-
5+
+
6-
6+
+
7-
7+
+
8-
8+
+
Subrack 0
8+
+
W4
Filler panel
9-
9+
+
11- 11+ 12- 12+

+
+
10- 10+
+
Filler panel
Filler panel
FillerFpanel
Issue 01 (2009-02-10)

4-3

System Principle
CAUTION
Table 4-1 lists the mappings between the cabinet components and the switches. Actual mappings
between cabinet components and switches differ. The mappings between the cabinet components
and the switches in this table are used for example purposes only.
Table 4-1 Mappings between the cabinet components and the switches
Cabinet
Switch
Cabinet Component
Air Circuit
Breaker (PCS)
Integraged
configuration
cabinet
(A7), A8,
(B7), and B8
SUBRACK-1
32A (4 PCS)
A2 and B2
MRMU
5A (2 PCS)
A3
LANS-1
5A (1 PC)
B3
LANS-0
5A (1 PC)
A1
KVMS
5A (1 PC)
A9, A10, B9,

and B10
SUBRACK-0
32A (4 PCS)
A5, A6, B5,

and B6
SUBRACK-2
50A (4 PCS)
(A7), A8,
(B7), and B8
SUBRACK-1
50A (4 PCS)
A9, A10, B9,

and B10
SUBRACK-0
50A (4 PCS)
Service
processing
cabinet
4.2 Monitoring Power Supplies

The MSOFTX3000 provides a power monitoring module to monitor power supplies, report
power status, and generate alarms on a real-time basis. The power monitoring module is housed
in the PDF.
Each cabinet is equipped with a PDF that is monitored by subrack 0 in the MSOFTX3000.
Figure 4-3 shows the connections for monitoring power supplies.
4-4

Issue 01 (2009-02-10)

System Principle
Figure 4-3 Connections for monitoring power supplies

Power distribution frame (PDF)
Power monitoring board
RS 485
RS 485
SDM
SDM
SMM
SMM
OSTA 2.0 subrack
BASE bus
OMU
The principles for monitoring power supplies are as follows:

l
In the PDF, a power monitoring board is designed to report power status.
The power monitoring board provides two RS 485 serial ports (active/standby) to connect
two external cables. The two external cables are connected to the COM2 ports on the SDMs
that are the back boards of the active and standby SMMs.
The SMM can process the information collected by the power monitoring board, and then
report the information to the OMU. The OMU transfers the information to the OMC. If
there is any fault, the OMC generates an alarm and sends it to the alarm box or subsystem.
A cabinet is usually equipped with multiple service processing subracks. The service processing
subrack, which is installed in the lowest part of the cabinet, monitors the PDF.
4.3 Monitoring Fan Boxes

The MSOFTX3000 provides integrated service processing subracks with built-in fan boxes. A
fan monitoring module is used to monitor fan status and to increase/decrease rotation speeds
based on temperature readings.
The SMM manages and monitors fan boxes through the IPMB bus.
Figure 4-4 shows how the SMM monitors fan boxes.
Issue 01 (2009-02-10)

4-5

System Principle
Figure 4-4 Monitoring fax boxes in an OSTA 2.0 subrack
SMM
SMM
IPMB
FAN
FAN
A fan box communicates with the SMM through the BMC. A fan box also reports an alarm
through the BMC. The BMC can increase or decrease rotation speeds as requested by the SMM.
4.4 Monitoring the Environment of a Telecommunications

Room
This topic describes how to monitor the environment of a telecommunications room. The PDF
and MRMU are used to monitor the environment of a telecommunications room. Monitoring
the environment of a telecommunications room is an optional function.
Figure 4-5 shows the structure of the monitoring system.
Figure 4-5 Structure of the monitoring system
Power distribution frame (PDF)
Power monitoring board
RS 485
Boolean
sensor
RS 485
SDM
SDM
SMM
SMM
OSTA 2.0 subrack
BASE bus
OMU
4-6

Issue 01 (2009-02-10)

System Principle
The PDF provides four external Boolean detection interfaces that are used to connect access,
water, smoke, and other sensors for information collection purposes. The way of reporting the
environment of a telecommunications room is the same as that of reporting the power status of
the PDF.
If more external Boolean detection interfaces or analog detection interfaces are required to
connect humidity, temperature, or other sensors, you can configure them through the MRMU.
Issue 01 (2009-02-10)

4-7

System Principle
Alarm Management System
About This Chapter

Alarm management is a part of the fault management system of the OMC. The fault management
system provides a comprehensive set of software that enables the system to detect, isolate, and
correct the faults of the managed device modules. When a fault, which might affect services,
occurs in the MSOFTX3000, the related module generates an alarm, and the alarm management
module reports the alarm to the operator. The operator can take a proper measure based on the
reported alarm to rectify the fault.
5.1 Subsystems of the Alarm Management System
The alarm system comprises the fault detection subsystem and alarm generation subsystem.
5.2 Alarm Severity and Alarm Type
This topic describes the alarm severities and alarm types.
5.3 Alarm Box and Alarm Console
This topic describes the functions and features of the alarm box and alarm console.
5.4 Alarm Report Path
This section describes the hardware alarm report path and software alarm report path.
5.5 Alarm Database
This topic describes the location of the alarm database and related limitation policies.
Issue 01 (2009-02-10)

5-1

System Principle
5.1 Subsystems of the Alarm Management System

The alarm system comprises the fault detection subsystem and alarm generation subsystem.
5.1.1 Fault Detection Subsystem
The hardware detection subsystem monitors the operating status of the equipment through
hardware detection and software detection. It reports the detected faults to the operator so that
the operator can rectify fault in time.
5.1.2 Alarm Generation Subsystem
The alarm generation subsystem collects information about faults, generates detailed alarm
records, and notifies maintenance personnel to take a proper measure.
5.1.1 Fault Detection Subsystem

The hardware detection subsystem monitors the operating status of the equipment through
hardware detection and software detection. It reports the detected faults to the operator so that
the operator can rectify fault in time.
l
Hardware detection
The hardware detections implemented by boards are as follows:
Board state (normal/abnormal or active/standby)
Clock
Temperature
Online/Offline state
Software detection
Logic errors can be detected through software detection. The logic errors that can be
detected are as follows:
CRC error
Memory error
Data consistency error
5.1.2 Alarm Generation Subsystem

The alarm generation subsystem collects information about faults, generates detailed alarm
records, and notifies maintenance personnel to take a proper measure.
The alarm generation subsystem comprises the host alarm module, OMU alarm server module,
alarm console, and alarm box. For details, see Figure 5-1. The host alarm module collects the
alarms reported from other modules and the iGWB, and forwards the collected alarms to the
OMU. The OMU alarm server module analyzes and stores all alarms (including those generated
by the OMU), instructs the alarm box to generate audio/visual alarms, and displays the alarm
details and recommended solutions on the alarm console of the workstation.
5-2

Issue 01 (2009-02-10)

System Principle
Figure 5-1 Alarm generation subsystem

Other host
software modules
LMT
Alarm module
Alarm server
module
Host
OMU
Alarm console
Alarm box
In addition to the alarm box and the alarm console, you can obtain alarm information from the
following:
l
Device panel on the workstation
Status indicators on each board: For the meanings of the status indicators on various boards,
see the HUAWEI MSOFTX3000 Mobile SoftSwitch Center Hardware Description or the
online Help of the LMT.
5.2 Alarm Severity and Alarm Type

This topic describes the alarm severities and alarm types.
5.2.1 Alarm Severity
The alarm severity indicates the severity level of an alarm.
5.2.2 Alarm Type
This topic describes the alarm types. An alarm type indicates the nature of the alarm.
5.2.1 Alarm Severity

The alarm severity indicates the severity level of an alarm.
In descending order of alarm severity, alarms are classified into four types:
l
Critical alarm: A critical alarm indicates that a critical problem exists somewhere in the
network. A critical problem can be the failure, overload, or system restarting of missioncritical boards. Critical alarms should be cleared immediately. Otherwise, system
breakdown may occur.
Major alarm: A major alarm indicates the failure of certain boards or links, such as
communication links. Urgent action is required to rectify the fault as this type of alarms
affects the QoS of the system.
Minor alarm: A minor alarm indicates a non-service affecting condition that should be
corrected. It can be a fault alarm or an event alarm against boards or links, for example,
PCM fault alarm. This type of alarms does not affect the QoS of the system, but you need
to locate and remove these faults in time.
Warning alarm: A warning alarm indicates a potential error that may affect the QoS of the
system, for example, board switchover and recovery. This type of alarms should be handled
based on the actual conditions.
Issue 01 (2009-02-10)

5-3

System Principle
5.2.2 Alarm Type

This topic describes the alarm types. An alarm type indicates the nature of the alarm.
The alarm report generated by the alarm console contains the alarm type. There are three alarm
types, namely, fault alarm, clear alarm, and event alarm.
l
Fault alarm: A fault alarm indicates the failure of hardware components or exception of
significant functions. When a fault alarm is cleared, a clear alarm is generated. A fault alarm
is paired with a clear alarm. Generally, fault alarms have a higher severity than event alarms.
Clear alarm: A clear alarm is generated when the failure of hardware components or
significant functions is corrected. A clear alarm is paired with a fault alarm.
Event alarm: An event alarm indicates an event that occurs in the system. It is an occasional
event. It reflects only the instant state of the system. There is no clear alarm for event alarms.
5.3 Alarm Box and Alarm Console

This topic describes the functions and features of the alarm box and alarm console.
5.3.1 Alarm Box
This topic describes functions and features of the alarm box.
5.3.2 Alarm Console
This topic describes functions and features of the alarm console.
5.3.1 Alarm Box

This topic describes functions and features of the alarm box.
Designed with an open structure, the alarm box provides powerful functions and features
convenient maintenance. The functions and features of the alarm box are as follows:
5-4
Provide real-time monitoring and accurately generate visible and audible alarms of the
following severities: critical, major, minor, and warning. Alarms are both visual and
audible. The alarms provide information to help the operator to take a proper measure.
Work in conjunction with the alarm console. This ensures optimal use of the alarm console
and helps the operator to perform operations with ease. The alarm box provides only
information about alarm severities. The alarm console provides the details of alarms. Thus,
the resources of the alarm box and the alarm console can be used efficiently.
Support flexible networking. The alarm box can be connected to the OMU or the alarm
workstation based on the actual conditions.
Provide powerful serial port communication functions. There are eight serial ports on the
alarm box, namely, four RS-232 serial ports and four RS-422 serial ports. Up to five serial
ports can be used for external communications at the same time. The communication
distance of RS-232 serial ports can reach 80 meters and that of the RS-422 serial ports can
reach 100 meters.
Provide the system-down notification function. When the system breaks down, a systemdown message is reported to the alarm box.
Provide the alarm sound function. The volume of the alarm sound produced by the alarm
box can be adjusted manually. Alarm sound for major, minor, and warning alarms can be
Issue 01 (2009-02-10)

System Principle
muted. Alarm sound for critical alarms, however, cannot be muted. The purpose is to keep
the operator remained of the critical fault in the system.
l
Provide the remote alarm and remote alarm sound control functions. By connecting to a
remote sound box, the alarm box can transfer alarm information to a maximum of 30 meters
in real time. Alarm sound can also be muted through the remote alarm sound control switch.
The remote alarm sound control switch can be a maximum of 30 meters away from the
alarm box. This is convenient for the operator to maintain the alarm box remotely.
Provide simplified fault location and convenient maintenance functions. The operator can
locate faults of the alarm box quickly and accurately through the maintenance serial port.
Support flexible power supply. The alarm box supports a variety of power supplies,
including 220 V AC, 110 V AC, and -48 V DC. This can meet the requirements of different
application scenarios.
Deliver proven environment specifications. The reliability, security, and electromagnetic

compatibility (EMC) features have passed the environment, EMC, and EMI tests.
Provide environment-friendly features. The alarm box is small, elegant, and easy to install.
It can display alarms in graphics.
For more details, see the user manual delivered with your alarm box.
5.3.2 Alarm Console

This topic describes functions and features of the alarm console.
The alarm box provides only visible and audible alarm severity information. The alarm console
on the workstation provides the details about alarms.
The alarm console is significant for maintenance personnel. To correctly display the alarms of
the MSOFTX3000 in real time, the alarm console provides alarm view, query, and management
functions as follows:
l
Provide real-time view and conditional real-time view of current alarms.
Support combined query of a particular category of alarms and dynamically update the
query results.
Provide detailed interpretation of alarm records and display the handling methods in real
time.
Support the printing of displayed alarms (in the alarm interpretation format) and the realtime printing of alarms.
Provide the mute and reset functions and support operations on the indicators.
5.4 Alarm Report Path

This section describes the hardware alarm report path and software alarm report path.
5.4.1 Hardware Alarm Report Path
This section describes the hardware report path.
5.4.2 Software Alarm Report Path
This topic describes the alarm report path of the host software and OMU software.
5.4.1 Hardware Alarm Report Path

This section describes the hardware report path.
Issue 01 (2009-02-10)

5-5

System Principle
All the boards of the MSOFTX3000 are intelligent boards. These boards can monitor their own
status, operational conditions, and external interfaces, test and indicate the operating status, and
report hardware abnormalities to upper-level equipment. The upper-level equipment can monitor
the operating status of the lower-level equipment, report the detected abnormalities to the higherlevel equipment, and perform an active/standby switchover as required. Hardware alarms are
classified into the following types:
l
Alarms about the physical hardware (such as the SMM, server board, and switch board)
and the environment, for example, board status (board present, board powered-off, board
not present), fan rotation speed, temperature, voltage, and current. This type of alarms is
reported by the SMM to the OMU through the maintenance plane.
Alarms about the hard disk, RAID, and network port. This type of alarms are reported by
the IMU to the OMU through the maintenance plane.
Figure 5-2 shows the hardware alarm report path of the MSOFTX3000.
Figure 5-2 Hardware alarm report path
Alarm
report
Alarm
report
Alarm
display
SMU
Base
bus
Base
bus
SWU
IMU
Alarm
console
OMU
Alarm
report
Alarm
report
Base
bus
Base
bus
Alarm
display
Alarm
box
5.4.2 Software Alarm Report Path

This topic describes the alarm report path of the host software and OMU software.
Software alarms are associated with events such as process fault, service process overload, and
CPU overload.
Both the host software and the OMU software can generate software alarms. For the host
software modules, alarms are sent to the alarm module, which then transfers the alarms to the
OMU alarm server module for processing. For the OMU, the alarms are directly sent to the alarm
server module for processing.
5.5 Alarm Database

This topic describes the location of the alarm database and related limitation policies.
5-6

Issue 01 (2009-02-10)

System Principle
5.5.1 Location of the Alarm Database

The alarm database is located in the OMU database. It stores information such as the alarm ID
and alarm type.
5.5.2 Alarm Limitation Policy
As the number of alarms increases, the free space on the memory is getting smaller. It is necessary
to adopt certain policy to ensure that the alarm database does not exceed the storage space of
the memory.
5.5.1 Location of the Alarm Database

The alarm database is located in the OMU database. It stores information such as the alarm ID
and alarm type.
For V200R008C01, the alarm database can store a maximum of 0.1 million alarm records.
5.5.2 Alarm Limitation Policy

As the number of alarms increases, the free space on the memory is getting smaller. It is necessary
to adopt certain policy to ensure that the alarm database does not exceed the storage space of
the memory.
The MSOFTX3000 adopts the following alarm limitation policies:
l
Alarm deletion strategy

History alarms can be retained for a maximum of 90 days only. Not more than 0.1 million
alarms can be stored on the system.
Alarm deletion time

If the system finds that the number of alarms exceeds 0.1 million when adding new alarms
to the alarm database, it deletes the earliest alarms automatically. At 03:00 a.m. every day,
the system checks whether any alarm has been retained for more than 90 days. If such an
alarm is found, the system deletes the alarm automatically.
Issue 01 (2009-02-10)

5-7

System Principle
Time Synchronization
About This Chapter

This topic describes the functions and principles of time synchronization.
6.1 NTP Function
The MSOFTX3000 uses the Network Time Protocol (NTP) to realize time synchronization. This
topic describes the working principles of the NTP.
6.2 Time Calibration Principles and Procedure
The OMU synchronizes with the NTP server (external time source). The internal modules of the
MSOFTX3000 synchronize with the OMU. This topic describes the time calibration principles
and procedure.
Issue 01 (2009-02-10)

6-1

System Principle
6.1 NTP Function

The MSOFTX3000 uses the Network Time Protocol (NTP) to realize time synchronization. This
topic describes the working principles of the NTP.
6.1.1 Definition of NTP
The network time protocol (NTP) is used for time synchronization. This topic provides the
definition of the NTP.
6.1.2 Working Principles of NTP
The NTP system contains two parts: the NTP client and the NTP server. This topic describes
the working principles of the NTP.
6.1.3 Networking of NTP
This topic describes the networking of the NTP.
6.1.1 Definition of NTP

The network time protocol (NTP) is used for time synchronization. This topic provides the
definition of the NTP.
The NTP is derived from the time protocol and ICMP timestamp messages. It is used for time
synchronization between the distributed time server and the client. The purpose of the NTP is
to enable the time synchronization between all devices across the network that have time and
ensure the time consistency between them. A device running the NTP can not only synchronize
with the time source but also serve as a time source for other devices. In this way, the time on
all devices is consistent after the devices exchange the time information and synchronize with
each other. In practice, an accuracy of 1 millisecond to 50 milliseconds can be achieved through
the NTP.
6.1.2 Working Principles of NTP

The NTP system contains two parts: the NTP client and the NTP server. This topic describes
the working principles of the NTP.
The NTP client and NTP server send the data packets carrying their respective time information
to each other. In this way, the NTP client obtains the time information. Then, the NTP client
figures out the best time through the time selection algorithm and correct the time. Figure 6-1
shows the interaction process and working principle of the time synchronization.
6-2

Issue 01 (2009-02-10)

System Principle
Figure 6-1 Principle diagram of time synchronization

NTP data packet 10:00:00 a.m.
NetWork
NTP Server
NTP Client (OMU)
NTP data packet 10:00:00 a.m. 11:00:01 a.m.
NetWork
NTP Server
NTP Client (OMU)
NTP data packet 10:00:00 a.m. 11:00:01 a.m. 11:00:01 a.m.
NetWork
NTP Server
NTP Client (OMU)

NTP packet arrived at 10:00:03 a.m.
NetWork
4
NTP Client (OMU)
NTP Server
The time synchronization process is as follows:

1.
The NTP client sends an NTP data packet requesting synchronization to the NTP server.
The data packet carries the timestamp of leaving the NTP client. For example, the timestamp
is 10:00:00 a.m., as shown in Figure 6-1.
2.
When the NTP data packet reaches the NTP server, the NTP server adds the timestamp of
itself, that is, 11:00:01 a.m..
3.
The NTP server sends the received data packet to the NTP client. The timestamp (11:00:02
a.m.) of the NTP server is added to this data packet.
4.
When the NTP client receives the response data packet from the NTP server, the NTP client
adds a new timestamp, that is, 10:00:03 a.m..
At present, the NTP client obtains sufficient time information to calculate the two important
parameters required for time correction:
l
Time delay of a cycle required when the NTP message is sent and received
Time offset between the NTP client and the NTP server
Therefore, the NTP client can set its own clock based on the two parameters to synchronize the
clock with that of the NTP server.
Issue 01 (2009-02-10)

6-3

System Principle
Figure 6-2 shows how to calculate the time offset and delay in the NTP.
Figure 6-2 Calculating method for time offset and delay
t0
t1
NTP Server
NTP Client
t2
t3
The NTP server sends the response packet to the NTP client. The response packet includes time
t0 at which the NTP client sends the request packet, time t1 at which the NTP server receives
the request packet, and time t2 at which the NTP server sends the response packet. The NTP
client can receive time t3 at which the response packet is received from the NTP server. The
methods for calculating the delay and time offset are as follows:
l
Delay = (t3 - t0) - (t2 - t1)
Offset = [(t1 - t0) + (t2 - t3)]/2

NOTE
Offset indicates the deviation between the node in the computer data network and the NTP server.
In general, the data transmission backbone network is configured with one or more NTP servers.
The nodes in the backbone data transmission network send the time synchronization request to
the NTP server. The clocks of the nodes in the entire network are synchronized through the NTP
time correction function.
6.1.3 Networking of NTP

This topic describes the networking of the NTP.
The time synchronization is better when the number of clock sources is smaller. Because of the
enormous network, it is not realistic to connect all devices in the network to the same time server.
Thus, in the Network Time Protocol (NTP) model, hierarchical structure that is often up to 15
layers is adopted. The main reference sources that are synchronized with the national standard
clock through a wired or wireless system are connected to the frequently visited resource such
as the backbone gateway. The main reference resources run in the network as primary time
servers.
The NTP nodes form the time trace system in hierarchical structure. The node on the top layer
(first layer) traces the national standard time. The node on the second layer traces the national
standard time through the node on the first layer. Each node keeps a certain precision time
according to its own clock. In addition, the node automatically sends the request for correcting
the time in appropriate correction cycle.
NTP is used to send the time information of the primary time servers to other time servers through
the network. In addition, it is used to check the clock of every server periodically to reduce the
error caused by the device or transmission fault. Some NTP hosts or gateways in the local area
network (LAN) run as secondary time servers. These secondary time servers send the time
information to other hosts in the LAN through the NTP. To improve the reliability, install less
6-4

Issue 01 (2009-02-10)

System Principle
accurate but cheaper radio clocks on the selected hosts as a backup. When the primary or
secondary time servers are faulty or when the communication between the hosts and the time
servers fails, the radio clocks can provide the time information. Figure 6-3 shows the networking
structure.
Figure 6-3 Networking structure
National standard time server
Primary time server
Layer 1
Layer 2
Secondary time server
Tertiary time server
Layer 3
Client
Layer 4
NOTE
The servers and clients are relative concepts. The device that provides the time is the server, and the device
that receives the time is the client.
6.2 Time Calibration Principles and Procedure

The OMU synchronizes with the NTP server (external time source). The internal modules of the
MSOFTX3000 synchronize with the OMU. This topic describes the time calibration principles
and procedure.
The OMU is the core functional entity for the time calibration of the MSOFTX3000. The NTP
server, OMU subsystem, host subsystem, and RTC subboard work together to calibrate the time
for the MSOFTX3000. The RealTime Clock (RTC) subboard, which is equipped with an
oscillator, provides accurate time. When the NTP server is unavailable, the MSOFTX3000
obtains the time from the RTC subboard. During the time calibration, the OMU can not only
Issue 01 (2009-02-10)

6-5

System Principle
function as a client to connect the NTP server but also function as a server to provide time for
the host. The NTP server may be a dedicated time server or embedded in the NMS.
Figure 6-4 shows the logical structure of the MSOFTX3000 time calibration system.
Figure 6-4 Logical structure of the MSOFTX3000 time calibration system
NTP Server
NTP Server
NTP Server
NTP
RTC
Master OMU
Slave OMU
RTC
U
P
B
NTP
S
M
M
U
P
B
U
P
B
NOTE
Up to four NTP servers can be connected to the MSOFTX3000. The NTP server and configuration
parameters are configurable.
An RTC subboard is attached to the back board of the OMU. If no NTP server is configured or the
configured NTP servers are unavailable, the OMU obtains the time from the RTC subboard and
provides the time for the host.
The MSOFTX3000 calibrates the system time according to the following procedure:
6-6
The active OMU synchronizes with the NTP server according to the fixed time. It inserts
the time into the operating system of itself and the RTC subboard on the back board. If
none of the NTP servers is available, the OMU synchronizes with the RTC subboard
according to the fixed time to set the system time. The OMU synchronizes with the NTP
server by using the NTP. Driver interfaces are adopted between the OMU and the RTC.
The standby OMU synchronizes with the active OMU. It inserts the time into the operating
system of itself and the RTC subboard on the back board. When the standby OMU
synchronizes with the active OMU, the active OMU must minimize the network delay. The
standby OMU does not synchronize with the NTP server unless the standby OMU changes
to the active state.
When providing time for the standby OMU and host, the active OMU first obtains the time
from the RTC. If the operation fails, the active OMU obtains the system time from its own
operating system.
The host synchronizes with the active OMU by using the NTP according to the fixed time.
If the communication between the host and the OMU fails, the boards run according to
their own time.

Issue 01 (2009-02-10)

System Principle
NOTE
Three time-related terms are described as follows:
Issue 01 (2009-02-10)
Universal Time Coordinated (UTC): The time of the time zone at 0 degrees geographic longitude.
Equivalent to the Greenwich Mean Time (GMT). Also called the standard time. The UTC time is
adopted by the NTP server.
Local mean time: It is the time of the local time zone without counting the daylight saving time
(DST). Also called the local standard time in this document.
Local time: It is the local mean time plus the DST offset. If the DST is not enabled or the date is not
in the DST period, the local time is the same as the local mean time.

6-7

System Principle
7 CDR and Charging
CDR and Charging
About This Chapter

The call detail record (CDR) and charging is an important function of the telecommunication
network. The MSOFTX3000 generates CDRs, pre-processes them, and sends them to the billing
center.
7.1 Basic Concepts
This topic describes the basic concepts related to charging.
7.2 CDR Generation
This section describes the mechanism, process, and scenarios of CDR generation.
7.3 CDR Delivery
This section describes the delivery process and the delivery modes for the original CDRs and
final CDRs.
7.4 CDR Storage
This section describes the storage modes of the original CDRs and final CDRs.
7.5 CDR Backup
This topic describes the backup modes of original CDRs and the first copy of the final CDRs.
Issue 01 (2009-02-10)

7-1

System Principle
7 CDR and Charging
7.1 Basic Concepts

This topic describes the basic concepts related to charging.
7.1.1 Charging Scheme
This topic describes the charging schemes of the MSOFTX3000.
7.1.2 CDR Classification
A CDR is a call detail record (CDR) generated by the MSOFTX3000. It is a charging data unit
stored in the memory of the WCCU/WCSU and on the hard disk of the iGWB. The format of
the data unit is defined. There are several ways to classify CDRs. The name of a CDR varies
according to the classification criteria.
7.1.3 CDR Interface
This section describes the CDR transfer protocols, formats of CDR files, and formats of CDR
contents.
7.1.4 CDR Encoding
This section describes the CDR encoding schemes.
7.1.1 Charging Scheme

This topic describes the charging schemes of the MSOFTX3000.
Host Charging
In this scheme, the host records all information on each call conversation, and generates a detail
CDR based on pre-determined charging data. A CDR refers to a data unit that is generated in
the host for a call and is used to accommodate original charging information in a particular
format.
Offline Charging
In this scheme, call CDRs are analyzed and processed according to the service provider's
requirements. The specific fee consumed by each subscriber or trunk during a period of time is
calculated with defined charging regulations taken into consideration. This process is carried
out on a dedicated device in the offline mode, and thus not conducted in real time. Generally, a
billing center is responsible for offline charging.
Online Charging
In this scheme, the online charging system is responsible for providing, in the shortest time, call
CDRs generated by the MSOFTX3000 to a settlement center through the network, so that service
provider can obtain the latest fee information of customers against possible or potential profit
loss.
The MSOFTX3000 charging system often uses the online charging scheme to implement
charging. The iGWB preprocesses CDRs, stores CDRs to a buffer, and provides billing
interfaces.
Real-Time Charging
In real-time charging mode, the system charges a subscriber for the ongoing service and deducts
payment from the account in real time. If the account balance is insufficient, the system sends
7-2

Issue 01 (2009-02-10)

System Principle
7 CDR and Charging
an instruction to forcibly terminate the ongoing service. In this mode, the charging response time
is measured by a time unit less than one second. A typical application scenario of real-time
charging is Prepaid Service (PPS), which is implemented in accordance with the CAMEL
protocol. In PPS charging mode, the account balance reduces as the call continues. When the
account balance is insufficient, the system releases the call.
7.1.2 CDR Classification

A CDR is a call detail record (CDR) generated by the MSOFTX3000. It is a charging data unit
stored in the memory of the WCCU/WCSU and on the hard disk of the iGWB. The format of
the data unit is defined. There are several ways to classify CDRs. The name of a CDR varies
according to the classification criteria.
Classification Based on the Storage Location

Based on the storage location, CDRs are classified into the following types:
l
Original CDRs: Original CDRs refer to the charging data units that are generated by the
MSOFTX3000 initially and stored in the memory of the WCCU/WCSU. In normal
circumstances, the MSOFTX3000 automatically transfers original CDRs over an internal
Ethernet to the iGWB in real time.
Final CDRs: After receiving original CDRs from the MSOFTX3000, the iGWB first stores
these CDRs on a hard disk. Then, the iGWB sorts the CDRs, converts the CDRs into the
required format, and saves the processed CDRs to the hard disks in certain classification
modes. These processed CDRs are called final CDRs. Final CDRs provide a key basis for
subscriber charging and cross-network settlement. In normal circumstances, the billing
center (BC) acquires final CDRs from the iGWB automatically and periodically.
Classification Based on the Generation Process

Based on the generation process, CDRs are classified into the following types:
l
Intermediate CDRs: If the duration of a call is longer than the value of the long-call CDR
timer, the system generates an intermediate CDR for every expiry of the timer.
Last CDRs: When releasing a call after the conversation is complete, the system generates
a last CDR.
If the duration of a call is shorter than the value of the long-call CDR timer, the system only
generates a last CDR that records all the activities of the call. If the duration of the call is longer
than the value of the long-call CDR timer, the system generates intermediate CDRs and a last
CDR. In this case, the last CDR records only the call activities during the last interval of the
timer.
NOTE
An intermediate CDR records the call activities only during an interval of the timer. The BC charges a
subscriber by accumulating the call expense in all the intermediate CDRs and the last CDR.
7.1.3 CDR Interface

This section describes the CDR transfer protocols, formats of CDR files, and formats of CDR
contents.
Issue 01 (2009-02-10)

7-3

System Principle
7 CDR and Charging
CDR Transfer Protocols

Using the standard FTP/FTAM protocol, the iGWB proactively or passively transfers the CDRs
generated by the MSOFTX3000 to the BC over an FTP interface or an FTAM interface.
Formats of CDR Files

The MSOFTX3000 supports CDR files in the following formats:
l
Binary format: Binary CDR files are used for the MSOFTX3000 to interwork with 2G
equipment. Binary CDR files are not recommended, except when the current office is a
reconstructed 2G office, a 2G office in China, or a special office.
ASN.1 format: The Abstract Syntax Notation One (ASN.1) standard describes complex
data structures explicitly and thus is widely used as a syntax notation standard for the
application layer. Both Huawei and the 3GPP organization recommend ASN.1 CDRs.
Formats of CDR Contents

By configuring the format database of CDR contents on the iGWB, you can ensure that the
iGWB supports the 3GPP-defined formats of CDR contents.
7.1.4 CDR Encoding

This section describes the CDR encoding schemes.
Binary Encoding Scheme

The binary encoding scheme adopts a data structure that is organized at a fixed length and in a
fixed format. Each field has a fixed position in a binary CDR.
ASN.1 Encoding Scheme

The ASN.1 encoding scheme adopts the Tag, Length, and Value (TLV) data structure. This
scheme defines basic data structures such as the Integer, Boolean, and octet string. A combination
of any of these basic data structures results in a more complex data structure.
An ASN.1 CDR consists of one or more TLV units. A field in the CDR is identified by an
identifier and is resolved based on the length indicator and the value of this field.
7.2 CDR Generation

This section describes the mechanism, process, and scenarios of CDR generation.
7.2.1 CDR Generation Mechanism
This section describes the mechanism of CDR generation.
7.2.2 CDR Generation Process
This topic describes the working process of the charging system.
7.2.3 CDR Generation Scenarios
This topic describes the CDR generation scenarios.
7-4

Issue 01 (2009-02-10)

System Principle
7 CDR and Charging
7.2.1 CDR Generation Mechanism

This section describes the mechanism of CDR generation.
Structure of the Charging System

When processing a call, the WCCU of the MSOFTX3000 generates original CDRs based on the
collected call data and stores them in the CDR pool. Through a specific sliding window protocol,
the MSOFTX3000 transfers the CDRs in the CDR pool to the iGWB with the help of the internal
communication system. The iGWB then stores, processes, and transfers CDRs to the BC through
the WAN/LAN. According to the information in final CDRs, the BC of a PLMN carrier generates
billing invoices for purposes of subscriber charging and cross-network settlement. Figure 7-1
shows the structure of the MSOFTX3000 charging system.
Figure 7-1 Structure of the MSOFTX3000 charging system
WAN/LAN
FTP/
FTAM
SWP
MSOFTX3000
Billing center
Network management
center
iGWB
MML
WAN/LAN
MML
OMU local maintenance

terminal
Local telecommunications room
OMU remote
maintenance terminal
Remote end
LAN: Local Area Network
WAN: Wide Area Network
FTP: File Transfer Protocol
MML: Human-Machine Language
FTAM: File Transfer Access and Management Protocol
Working Principles of the Charging System

Figure 7-2 shows the logical structure of the MSOFTX3000 charging system.
Issue 01 (2009-02-10)

7-5

System Principle
7 CDR and Charging
Figure 7-2 Logical structure of the charging system
Call control
module
CDR pool
iGWB
BC
WCCU
The charging system of the MSOFTX3000 consists of the WCCU, iGWB, BC, and
interconnection accessories.
l
Call control module of the WCCU

The call control module generates original CDRs and stores them temporarily in the CDR
pool of the WCCU.
CDR pool of the WCCU

The CDR pool is an area in the memory that stores the CDRs generated by the call control
module of the WCCU. The WCCU transfers the stored CDRs to the iGWB in real time.
The active WCCU sends CDR data to the standby WCCU in real time, which minimizes
data loss caused by board failure.
The MSOFTX3000 defines alarms and call restriction thresholds for the free space of the
CDR pool. When 20% of the WCCU CDR pool is occupied, an alarm is generated, but
calls are not restricted and the CDRs are not affected. When the free space of the CDR pool
is less than 1% of the CDR pool size, an alarm is generated, and calls are restricted. The
CDRs are affected. You can configure the thresholds of the free space for the CDR pool in
command line mode. When the free space is below the threshold, the system generates an
alarm and determines the numbers of calls to be restricted according to the free space of
the CDR pool and the CDR increase rate.
NOTE
Before loading data onto the WCCU or upgrading the WCCU, you must run CDR-related commands on
the local maintenance terminal (LMT), for example, running a command to initiate immediate transfer of
original CDRs to the iGWB, to protect the WCCU/WCSU against possible CDR loss.
l
iGWB
The iGWB resides between the MSOFTX3000 and the BC. It receives, preprocesses, and
caches CDRs. The iGWB also functions as a billing interface.
BC
Based on the final CDRs received from the iGWB, the BC generates billing invoices for
subscribers.
The BC is not a part of the MSOFTX3000.
7.2.2 CDR Generation Process

This topic describes the working process of the charging system.
Figure 7-3 shows the working process of the charging system.
7-6

Issue 01 (2009-02-10)

System Principle
7 CDR and Charging
Figure 7-3 Working process of the charging system

MSOFTX3000
CDR
pool of
the
WCCU
CDR
pool of
the
WCCU
Active
iGWB
Standby
iGWB
Communication system of the MSOFTX3000
BC
1.
When a call is terminated, the WCCU generates and temporarily stores the charging
information in its buffer (that is, the CDR pool).
2.
The content and format of the original CDRs generated by the MSOFTX3000 do not meet
the requirements of the BC. Thus, the CDRs must be preprocessed before being sent to the
BC. The iGWB resides between the MSOFTX3000 and the BC. It is responsible for
receiving, preprocessing, and temporarily storing CDRs in a buffer. It is also responsible
for providing the billing interface function. The WCCU sends CDRs from the CDR pool
to the iGWB in real time through the BASE bus. The iGWB stores the original CDRs as
files.
NOTE
For details about the working principles of and operations on the iGWB, refer to the HUAWEI
iGateway Bill User Manual.
3.
Issue 01 (2009-02-10)
The iGWB sorts the original CDRs, converts them from the binary format to the text format
or ASN.1 format, and generates the final CDRs. The iGWB then saves the final CDRs to
different channels based on the classification of CDRs. Figure 7-4 shows how the iGWB
preprocesses CDRs.

7-7

System Principle
7 CDR and Charging
Figure 7-4 Procedure for preprocessing CDRs by the iGWB

MSOFTX3000
Generates and
transmits CDRs
Service flow of access point process

Receives CDRs, and through a particular
protocol ensures that CDRs are received
without repetition or loss.
Network module
Directly saves the CDRs received by

network module and generate original
CDRs.
Front saving module
Combines and sorts CDRs according to the

requirement, and then transmits them to the
back saving module.
CDR processing module
Saves the CDRs by channel, generate final

CDRs, and submits them to the billing
center.
FTP/
FTAM
BC
Back saving module
NOTE
The system is configured with active/standby iGWBs, which back up the CDRs in real time to avoid
loss of charging data due to the failure of the active iGWB.
For details about the working principles of and operations on the iGWB, refer to the HUAWEI
iGateway Bill User Manual.
4.
To ensure reliable transfer of final CDRs to the BC, the iGWB communicates with the CDR
collector of the BC through the standard File Transfer Protocol (FTP) or File Transfer
Access & Management Protocol (FTAM).
NOTE
If the FTP protocol is in use, the iGWB supports two modes of CDR transfer. In pull mode, the CDR
collector (client) acquires CDRs from the iGWB (server) in a proactive manner. In push mode, the
iGWB (client) transfers CDRs to the CDR collector (server) in a proactive manner.
If the FTAM protocol is in use, the iGWB serves as the responder and the CDR collector as the
initiator. The iGWB communicates with the CDR collector in a way similar to that with the FTP
protocol.
7.2.3 CDR Generation Scenarios

This topic describes the CDR generation scenarios.
The MSOFTX3000 supports more than 40 types of CDRs in order to meet various requirements
of carriers. Table 7-1 describes the generation scenarios for each type of CDRs.
7-8

Issue 01 (2009-02-10)

System Principle
7 CDR and Charging
Table 7-1 Generation scenarios of original CDRs

CDR Type
Whether
Final CDR
Is in ASN.1
Format
Whether
Final CDR
Is in Binary
Format
CDR Generation Scenarios
MOC CDR
(including
emergency
call CDRs)
If a call originated by a non-IN mobile

subscriber is answered, the MSC generates
a mobile-originated call (MOC) CDR for
the caller when the call is terminated or the
long-call CDR timer expires.
MTC CDR
If a call is received by a non-IN mobile

subscriber or by an IN mobile subscriber
whose VMSC does not provide the SSP
function, the MSC generates a mobileterminated call (MTC) CDR for the callee
when the call is terminated or the long-call
CDR timer expires.
CFW CDR
Subscriber B is a non-IN mobile subscriber

and is provisioned with the call forwarding
service. Subscriber C is the forwarded-to
subscriber of B. When subscriber A calls
subscriber B, subscriber B has the incoming
call addressed to subscriber C. If subscriber
C answers the call, the MSC generates a call
forwarding (CFW) CDR for subscriber B
CDR timer expires.
If subscribers A, B, and C are registered
with the same MSC/VLR, the MSC
generates an MOC CDR for subscriber A,
a CFW CDR for subscriber B, and an MTC
CDR for subscriber C when the call is
terminated or the long-call CDR timer
expires.
MO_SMS
CDR
If a short message sent by a mobile

subscriber reaches the short message center
(SMC) successfully, the MSC generates a
mobile-originated SMS (MO_SMS) CDR
for the sender.
During short message communication,
characters of a short message are
transmitted over a signaling channel.
Compared with the CDR for an ordinary
call, an SMS CDR additionally records the
content of a short message, result of the
short message service, number of bytes in
the short message, and SMC address.
Issue 01 (2009-02-10)

7-9

System Principle
7 CDR and Charging
CDR Type
Whether
Final CDR
Is in ASN.1
Format
Whether
Final CDR
Is in Binary
Format
MT_SMS
CDR
If a mobile subscriber receives a short

message from the SMC successfully, the
MSC generates a mobile-terminated SMS
(MT_SMS) CDR for the recipient.
TRANSIT
CDR
When an incoming trunk originates a call,

the MSC (usually a TMSC) analyzes the
call and connects it to an outgoing trunk. In
this case, the call is neither originated nor
terminated in the local MSC. To calculate
the charge for the use of inter-office trunks,
the MSC generates a TRANSIT CDR when
the call is terminated or the long-call CDR
timer expires.
GWO CDR

the MSC (usually a GMSC) analyzes the
terminated in the local MSC. If the type of
the incoming office direction is "Local
network" and the type of the outgoing office
direction is "Other network" (Other PLMN
or PSTN), the MSC generates an outgoing
gateway exchange (GWO) CDR when the
call is terminated or the long-call CDR
timer expires.
GWI CDR

the MSC (usually a GMSC) analyzes the
terminated in the local MSC. If the type of
the incoming office direction is "Other
network" (Other PLMN or PSTN) and the
type of the outgoing office direction is
"Local network", the MSC generates an
incoming gateway exchange (GWI) CDR
CDR timer expires.
Only the ASN.1 encoding scheme provides
a GWI CDR.
7-10

Issue 01 (2009-02-10)

System Principle
7 CDR and Charging
CDR Type
Whether
Final CDR
Is in ASN.1
Format
Whether
Final CDR
Is in Binary
Format
ROAM CDR

a ROAM CDR.
A call is addressed to a non-IN mobile
subscriber roaming outside the home
PLMN. If the call must be routed to the
GMSC of the home PLMN, the GMSC
generates a ROAM CDR for the callee
CDR timer expires.
Location
Update
(VLR) CDR
CALL
ATTEMPT
CDR

a Location Update (VLR) CDR.
When a mobile subscriber updates the
location with the VLR, the local MSC
generates a Location Update (VLR) CDR.
When a call is a transit call, an internetwork transit call, a call routed out of the
GMSC, or a call routed to the GMSC, the
MSC generates a CALL ATTEMPT CDR
if the call setup fails.
A CALL ATTEMPT CDR is used to record
the network resources used by an
unsuccessful call. It is the same as a
TRANSIT CDR, an OT_TRANSIT CDR,
a GWO CDR, or a GWI CDR, except that
the cause value of call release in the CALL
ATTEMPT CDR is unsuccessfulCallAttempt. Based on the cause value of call
release, the BC sorts out a CALL
ATTEMPT CDR from other similar CDRs.
Only the binary encoding scheme provides
a CALL ATTEMPT CDR.
Issue 01 (2009-02-10)

7-11

System Principle
7 CDR and Charging
CDR Type
Whether
Final CDR
Is in ASN.1
Format
Whether
Final CDR
Is in Binary
Format
MOI CDR
Assume that the MSC in office A cannot

function as the SSP, the MSC in office B
can function as the SSP, office A routes the
IN calls in office A to office B through the
Overlay mode, and the MSC in office B
triggers the IN services. When a non-IN
subscriber in office A or incoming trunk
calls IN subscriber X (non-forwarding call),
office A routes the call to office B.
Therefore, office A cannot obtain the
precise location of IN mobile subscriber X.
After triggering the IN service, office B can
obtain the precise location of IN mobile
subscriber X. If subscriber X answers the
call, when the call ends or the timer of long
time call CDRs expires, the MSC in office
B generates a CDR called IN pickup CDR
or MOI CDR. The CDR is provided for the
BC, and is used to charge the caller
precisely.
The MOI CDR is generated only after the
Overlay incoming call triggers the called IN
service. When the mobile IN network
adopts networking of the target network,
the MSC does not generate the MOI CDR.
Only the binary encoding scheme provides
an MOI CDR.
LCS CDR
Y
(including the
MT-LR, MOLR, and NILR)
If the MSC receives a location request of

any type from the BSC or the RNC, the
MSC generates a CDR called location
service CDR or LCS CDR for the location
operation. The LCS CDRs are classified
into the following types: MT-LR, MO-LR,
and NI-LR.
The LCS CDR records the location method,
location time, and location results.
an LCS CDR.
7-12

Issue 01 (2009-02-10)

System Principle
7 CDR and Charging
CDR Type
Whether
Final CDR
Is in ASN.1
Format
Whether
Final CDR
Is in Binary
Format
SS_ACT
CDR
When a mobile subscriber performs a call

unrelated operation, such as registering,
canceling, activating and deactivating the
supplementary service (SS), the MSC
generates a CDR called supplementary
service CDR or SS_ACT CDR for the
operation.
an SS_ACT CDR.
CHECK_IM
EI CDR
If the MSC invokes the Check IMEI flow

in the process of the location update and the
service access, the MSC generates a CDR
called check IMEI CDR or CHECK_IMEI
CDR.
a CHECK_IMEI CDR.
QUERY_HL
R CDR
During a call connection, if the callee is a

non-IN mobile subscriber, the MSC
requests route information from the HLR
through the MAP signaling, and the HLR
returns the MSRN to the MSC through the
MAP signaling, the MSC generates a CDR
called HLR Interrogation CDR.
If the callee is an IN mobile subscriber, the
MSC needs to query the HLR twice. By
default, the MSC generates an HLR
Interrogation CDR when querying the HLR
for the second time. If you set Ticket
control flag to Generate HLR query CDR
after getting T-CSI by using MOD
GBILLCTRL, the MSC generates an HLR
Interrogation CDR when querying the HLR
for the first time. That is, the MSC generates
two HLR Interrogation CDRs.
an HLR Interrogation CDR.
Issue 01 (2009-02-10)

7-13

System Principle
7 CDR and Charging
CDR Type
Whether
Final CDR
Is in ASN.1
Format
Whether
Final CDR
Is in Binary
Format
TCAMEL
CDR
During a call connection, if a mobile

subscriber registers the CAMEL service
(with the T-CSI), receives a call, and
answers the call, the GMSC (SSP)
triggering the IN service generates a CDR
called TCAMEL callee CDR or TCAMEL
CDR when the call is terminated or the
long-call CDR timer expires.
a TCAMEL CDR.
CommonEqu
ip CDR
During a call connection or conversation, if

the MSC in office A uses the public device
resources (such as conference resources) in
office A or in the MSC of office B, the MSC
in office A generates a CDR called
Common Equipment Usage CDR or
CommonEquip CDR.
a Common Equipment Usage CDR.
7.3 CDR Delivery

This section describes the delivery process and the delivery modes for the original CDRs and
final CDRs.
7.3.1 CDR Delivery Process
This topic describes the CDR delivery process.
7.3.2 Delivery Modes of Original CDRs
This section describes the delivery modes of original CDRs.
7.3.3 Delivery Modes of Final CDRs
This section describes the delivery modes of final CDRs.
7.3.1 CDR Delivery Process

This topic describes the CDR delivery process.
The WCCU is responsible for charging in the MSOFTX3000. The charging information is first
stored in the host CDR buffer, and then transferred to the iGWB through the CDR delivery
process. On the iGWB, the charging information is stored in the format of files. The charging
information on the iGWB is sent to the billing center (BC) periodically over a data link. Figure
7-5 shows the process of CDR generation and storage.
7-14

Issue 01 (2009-02-10)

System Principle
7 CDR and Charging
Figure 7-5 Process of CDR generation and storage
WCCU module
Host CDR pool
UDP
connection
on the Base
plane
WCCU module
iGWB
WAN/
LAN
BC
Host CDR pool
MSOFTX3000
1.
After each conversation, the WCCU generates original CDRs and stores them in the CDR
buffer of the board.
2.
The MSOFTX3000 sends the CDRs in the CDR pools of the WCCU to the iGWB in real
time through the UDP connection on the Base plane. The CDRs are stored in the format of
CDR files on the iGWB to form the original CDRs.
3.
If the iGWB communicates with the CDR collector in the BC through the FTP, the
following two modes are supported:
l
The iGWB serves as the server, and the CDR collector serves as the client. The CDR
collector actively collects CDR files from the iGWB.
The iGWB serves as the client, and the CDR collector serves as the server. The iGWB
actively sends CDR files to the BC.
NOTE
If the iGWB communicates with the CDR collector through FTAM, the iGWB can serve as the responder,
the CDR collector as the initiator, and the communication mode will be similar to that when the FTP is
adopted.
7.3.2 Delivery Modes of Original CDRs

This section describes the delivery modes of original CDRs.
The original CDRs are generated by the MSOFTX3000 and are stored in the memory of the
WCCU. After the original CDRs are generated, the host combines all the CDR transmission
paths of the WCCU through the UDP connection of the Base plane. The CDRs are stored in the
format of CDR files on the iGWB.
7.3.3 Delivery Modes of Final CDRs

This section describes the delivery modes of final CDRs.
After receiving the original CDRs, the iGWB combines and sorts the CDRs and converts their
formats to form the final CDRs that comply with the requirement of the BC. The final CDRs
are categorized and stored in the hard disks of the iGWB. The iGWB sends the final CDRs to
the BC through the FTP or FTAM.
Issue 01 (2009-02-10)

7-15

System Principle
7 CDR and Charging
7.4 CDR Storage

This section describes the storage modes of the original CDRs and final CDRs.
The iGWB stores the original CDRs from the host, and then categorizes them and converts their
format to form the final CDRs. Subsequently, the iGWB stores the final CDRs in a particular
format. This section describes the generation, naming principles, and storage modes of the
original CDRs and final CDRs.
7.4.1 Storage of Original CDRs
This topic describes the naming principles and storage structures of the original CDRs on the
iGWB.
7.4.2 Storage of Final CDRs
This topic describes the naming principles and directory structures for the storage of final CDRs
on the iGWB.
7.4.1 Storage of Original CDRs

This topic describes the naming principles and storage structures of the original CDRs on the
iGWB.
The original CDRs are first saved in D:\frontsave based on the access points, such as X3KM,
and then saved by date under each access point respectively. Figure 7-6 shows the directory
structure for the storage of original CDRs.
Figure 7-6 Directory structure for the storage of original CDRs
D:\FrontSave
X3KM
Date
Original CDR file
Original CDR file
Date
Original CDR file
Original CDR file
The original CDRs are stored in folders named by date, that is, the original CDRs generated
within the same day are saved in the same folder named based on the current date. For example,
all the original CDR files generated on January 1, 2009 are stored in the folder named 20090101.
The length of an original CDR file can be configured as along as it does not exceed the maximum
value.
7-16

Issue 01 (2009-02-10)

System Principle
7 CDR and Charging
The original CDR files are named in the format of b + a nine-digit serial number + .bil. For
example, b000000001.bil and b000000002.bil.
7.4.2 Storage of Final CDRs

This topic describes the naming principles and directory structures for the storage of final CDRs
on the iGWB.
Normally, the final CDRs are saved in the E:\backsave path in duplicate. Figure 7-7 shows the
directory structure for the storage of final CDRs.
Figure 7-7 Directory structure for the storage of final CDRs
E:\backsave
E:\backsave
X3KM
Second
Channel 1
X3KM
Date
Channel 1
Final CDR file
Final CDR file
Final CDR file
Final CDR file
Date
Channel n
Final CDR file
Final CDR file
Final CDR file
Final CDR file
Channel n
Date
Final CDR file
Final CDR file

Date
Final CDR file
Final CDR file
The first copy of the final CDRs is saved in the directory of e:\backsave\AccessPointName
\ChannelName\Date by access point, then by channel, and then by date.
The second copy is saved in e:\backsave\Second\AccessPointName\ChannelName. Different
from the first copy, the second copy is not saved separately by date in the channels. The directory
for saving the second copy is accessible to the BC and must be deleted in real time after the
CDRs are collected by the BC. Normally, no CDRs can be accumulated in this directory.
NOTE
Final CDR files can also be stored under the channels directly. In normal cases, you are advised to store
final CDR files under the directory by channel and date.
Issue 01 (2009-02-10)

7-17

System Principle
7 CDR and Charging
Channel
The CDR files meeting particular requirements are stored in the same channel. For example,
CDR files of different types can be stored in different channels, that is, the CDRs of a particular
type are stored in one channel.
Naming Principles of Final CDR Files

A final CDR file is named in the format of prefix + serial number + the symbol "." + suffix. For
example, b00000001.dat.
l
Prefix
The prefix is optional and can be any string of characters. Usually, the office name is used
as the prefix. By default, the prefix is the character b.
Serial number
The serial number is mandatory. By default, it is an eight-digit number starting from
00000001 with an increment of 1. In addition, the serial number must be smaller than
99999999.
Suffix
The suffix can be configured. By default, it is dat.
Final CDR Files

The generation of a final CDR file depends on two conditions: size of the file and generation
duration of the file. The two conditions are equally effective. After being created, a final CDR
file is closed when the file size or generation duration reaches the upper limit. Subsequently, a
new final CDR file is created.
A final CDR file contains one or more final CDRs, as shown in Figure 7-8.
Figure 7-8 Format of a final CDR file
Final CDR 1Final CDR 2Final CDR 3
Final CDR n
Format of Final CDRs

Final CDRs are stored in final CDR files. The charging system of the MSOFTX3000 supports
22 types of final CDRs. For details, refer to Appendix A "Format of Final CDRs."
7.5 CDR Backup

This topic describes the backup modes of original CDRs and the first copy of the final CDRs.
CDR backup on the iGWB is a network backup function. To ensure the security of CDRs, the
iGWB can back up the CDR files to the peer iGWB node or the third-party server in real time.
CDR backup on the iGWB is implemented by using the FTP. During the CDR backup process,
the iGWB serves as the FTP client, and the backup destination serves as the FTP server. Figure
7-9 shows the implementation principle of CDR backup.
7-18

Issue 01 (2009-02-10)

System Principle
7 CDR and Charging
Figure 7-9 Implementation principle of CDR backup

iGWB
(FTP Client)
CDR file
FTP Server
Before backing up the CDRs, ensure that the backup source and destination have enabled the
FTP function and that their available disk space is sufficient. You also need to configure data
for the backup of the CDRs, for example, the IP address of the FTP server, IP address for
communication between the iGWB and the FTP server, user account and password for logging
in to the FTP server, backup time, backup task number, backup source path, and backup
destination path.
After the related data is configured on the iGWB, the system starts searching for all the original
CDR files at the time point configured on the iGWB, and then backs up in sequence the CDR
files to the FTP server. If the interval between two consecutive searching operations is
configured, the system searches for a second time the original CDR files in the specified path
within the backup period and backs up the newly generated original CDR files to the FTP server.
7.5.1 Backup of Original CDRs
This topic describes the backup mode of original CDRs.
7.5.2 Backup of Final CDRs (the First Copy)
This topic describes the backup mode of final CDRs (the first copy).
7.5.1 Backup of Original CDRs

This topic describes the backup mode of original CDRs.
For the backup of the original CDRs, one access point usually maps one backup task, that is,
you need to create a CDR backup task with the backup source path set to the path of the original
CDR, and the information on the access point of the backup source path is required. For example,
you can use D:\frontsave\X3KM as the backup source path.
7.5.2 Backup of Final CDRs (the First Copy)

This topic describes the backup mode of final CDRs (the first copy).
The iGWB supports the backup of final CDRs (the first copy). For the backup of final CDRs,
one channel usually maps one backup task, that is, you need to create a CDR backup task with
the backup source path set to the path of the final CDRs, and the information on the channel of
the backup source path is required. For example, you can use D:\backsave\X3KM\detail as the
backup source path.
Issue 01 (2009-02-10)

7-19

System Principle
8 Final CDRs
Final CDRs
About This Chapter

This topic describes the types and formats of final CDRs supported by the system.
8.1 Types of Final CDRs
This topic describes the types of final CDRs supported by the system.
8.2 Format of Final CDRs
This topic describes the formats of final CDRs supported by the system.
Issue 01 (2009-02-10)

8-1

System Principle
8 Final CDRs
8.1 Types of Final CDRs

This topic describes the types of final CDRs supported by the system.
The MSOFTX3000 supports the following types of final CDRs:
l
Mobile originated call CDR (MOC CDR) including emergency call CDR
Mobile terminated call CDR (MTC CDR)
Gateway outgoing call CDR (GWO CDR)
Transit call CDR (TRANSIT CDR)
Supplementary service actions CDR (SS_ACT CDR)
Mobile terminated short message service CDR (MT_SMS CDR)
Mobile originated short message service CDR (MO_SMS CDR)
Call attempt CDR (CALL_ATTEMPT CDR)
Gateway incoming call CDR (GWI CDR)
Roaming CDR (ROAM CDR)
Common equipment usage CDR (CommonEquip CDR)
Call forwarding CDR (CFW CDR)
Mobile originated - instead CDR (MOI CDR)
Terminated CAMEL visit CDR (TCAMEL CDR)
Location service CDR (LCS CDR)
Check IMEI CDR (Check_IMEI CDR)
HLR interrogation CDR (QUERY_HLR CDR)
8.2 Format of Final CDRs

This topic describes the formats of final CDRs supported by the system.
The formats of final CDRs are related to the types of final CDRs in the MSOFTX3000. For
details, see HUAWEI iGateway Bill User Manual.
8-2

Issue 01 (2009-02-10)

System Principle (V200R008C01 01)

Încărcat de

Informații document

Titlu original

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

System Principle (V200R008C01 01)

Încărcat de

Drepturi de autor:

Formate disponibile

HUAWEI MSOFTX3000 Mobile SoftSwitch Center

Huawei Proprietary and Confidential

Huawei Technologies Co., Ltd.

Huawei Industrial Base

Copyright Huawei Technologies Co., Ltd. 2009. All rights reserved.

Trademarks and Permissions

Huawei Proprietary and Confidential

HUAWEI MSOFTX3000 Mobile SoftSwitch Center

2 Service Processing Subsystem.................................................................................................2-1

Huawei Proprietary and Confidential

HUAWEI MSOFTX3000 Mobile SoftSwitch Center

3 Maintenance Management Subsystem..................................................................................3-1

4 Environment Monitoring Subsystem.....................................................................................4-1

5 Alarm Management System.....................................................................................................5-1

Huawei Proprietary and Confidential

HUAWEI MSOFTX3000 Mobile SoftSwitch Center

5.3.1 Alarm Box..............................................................................................................................................5-4

7 CDR and Charging.....................................................................................................................7-1

Huawei Proprietary and Confidential

HUAWEI MSOFTX3000 Mobile SoftSwitch Center

Huawei Proprietary and Confidential

HUAWEI MSOFTX3000 Mobile SoftSwitch Center

Figure 6-3 Networking structure..........................................................................................................................6-5

Huawei Proprietary and Confidential

HUAWEI MSOFTX3000 Mobile SoftSwitch Center

Huawei Proprietary and Confidential

HUAWEI MSOFTX3000 Mobile SoftSwitch Center

About This Document

About This Document

Network planning engineers

This chapter describes the MSOFTX3000 with respect to

This chapter describes the service processing subsystems

Huawei Proprietary and Confidential

HUAWEI MSOFTX3000 Mobile SoftSwitch Center

About This Document

This chapter describes the maintenance management

This chapter describes the environment monitoring

5 Alarm Management System

This chapter describes the alarm subsystem of the

This chapter describes the clock synchronization system of

7 CDR and Charging

This chapter describes the billing system of the

This chapter presents the formats of the final CDRs in

Huawei Proprietary and Confidential

HUAWEI MSOFTX3000 Mobile SoftSwitch Center

About This Document

Times New Roman

Normal paragraphs are in Times New Roman.

Names of files, directories, folders, and users are in boldface.

Book titles are in italics.

Terminal display is in Courier New.

The keywords of a command line are in boldface.

Command arguments are in italic.

Items (keywords or arguments) in square brackets [ ] are optional.

Alternative items are grouped in braces and separated by vertical

Optional alternative items are grouped in square brackets and

Alternative items are grouped in braces and separated by vertical

Optional items are grouped in brackets and separated by vertical

Buttons, menus, parameters, tabs, window, and dialog titles are

Multi-level menus are in boldface and separated by the ">" signs.

Press the keys concurrently. For example, pressing Ctrl+Alt

Huawei Proprietary and Confidential

HUAWEI MSOFTX3000 Mobile SoftSwitch Center