Professional Documents
Culture Documents
System Principle (V200R008C01 01)
System Principle (V200R008C01 01)
V200R008C01
System Principle
Issue
01
Date
2009-02-10
Huawei Technologies Co., Ltd. provides customers with comprehensive technical support and service. For any
assistance, please contact our local office or company headquarters.
Website:
http://www.huawei.com
Email:
support@huawei.com
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.
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
Contents
Issue 01 (2009-02-10)
Contents
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
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
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)
Figures
vi
Issue 01 (2009-02-10)
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
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 administrators
Organization
This document consists of 8 chapters and is organized as follows.
Issue 01 (2009-02-10)
Chapter
Description
1 System Architecture
2 Service Processing
Subsystem
Chapter
Description
3 Maintenance Management
Subsystem
4 Environment Monitoring
Subsystem
6 Time Synchronization
8 Final CDRs
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)
General Conventions
Convention
Description
Boldface
Italic
Courier New
Command Conventions
Convention
Description
Boldface
Italic
[]
{ x | y | ... }
[ x | y | ... ]
{ x | y | ... } *
[ x | y | ... ] *
GUI Conventions
Convention
Description
Boldface
>
Keyboard Operation
Issue 01 (2009-02-10)
Format
Description
Key
Press the key. For example, press Enter and press Tab.
Key 1+Key 2
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
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.
Issue 01 (2009-02-10)
1 System Architecture
System Architecture
Issue 01 (2009-02-10)
1-1
1 System Architecture
1-2
Issue 01 (2009-02-10)
1 System Architecture
MRMU
LAN Switch
KVMS
Subrack
PDB
1-3
1 System Architecture
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)
1 System Architecture
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 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.
Issue 01 (2009-02-10)
1-5
1 System Architecture
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#
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)
1 System Architecture
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.
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-7
1 System Architecture
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).
Issue 01 (2009-02-10)
1 System Architecture
IPMB bus
Base bus
Fabric bus
Issue 01 (2009-02-10)
1-9
1 System Architecture
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
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)
1 System Architecture
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
1 System Architecture
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:
Issue 01 (2009-02-10)
1 System Architecture
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.
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:
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
1-13
1 System Architecture
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.
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)
1 System Architecture
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.
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-15
1 System Architecture
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).
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)
1 System Architecture
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.
Issue 01 (2009-02-10)
1-17
1 System Architecture
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
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.
Issue 01 (2009-02-10)
Issue 01 (2009-02-10)
2-1
SS7 signaling over M2UA, including TUP, ISUP, SCCP, and upper-layer user protocols
2-2
Issue 01 (2009-02-10)
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
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.
Issue 01 (2009-02-10)
2-3
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.
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)
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.
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.
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.
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.
Issue 01 (2009-02-10)
2-5
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
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.
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.
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.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
Issue 01 (2009-02-10)
3.
After MAC layer processing of the messages, the IFM process transfers the IP messages
to the USI through a fixed connection.
4.
The USI board processes the IP messages, and sends them out of the MSOFTX3000 through
the network cable.
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
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 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
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 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.
After MAC layer processing of the messages, the IFM process transfers the IP messages
to the USI through a fixed connection.
4.
The USI board processes the IP messages, and sends them out of the MSOFTX3000 through
the network cable.
2-8
Issue 01 (2009-02-10)
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
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 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
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.
After MAC layer processing of the messages, the IFM process transfers the IP messages
to the USI through a fixed connection.
4.
The USI board processes the IP messages, and sends them out of the MSOFTX3000 through
the network cable.
Issue 01 (2009-02-10)
Issue 01 (2009-02-10)
3-1
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)
1.
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
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.
Data configuration
Maintenance
The LMT runs Windows XP operating system. It can be connected to the OMU through a web
browser for performance management purposes.
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)
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.
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
LAN switch
Active OMU
Heartbeat
Standby OMU
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)
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
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.
Issue 01 (2009-02-10)
3-7
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.
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.
Scalability
The OMU provides high scalability through the following ways:
3-8
Issue 01 (2009-02-10)
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:
Memory usage
Memory dumping
Memory contents
Front panel
The front panel provides the following functions:
Device management
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
Alarm name
Alarm level
Issue 01 (2009-02-10)
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-11
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)
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.
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.
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
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.
Write
Memory
OMU
Load
Read
Local
storage
media
BASE bus
Data bus
Host board
3-14
Issue 01 (2009-02-10)
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.
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.
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
BIOS
LBP
NBP
OS (Linux)
OMU
Starter
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.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
Issue 01 (2009-02-10)
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.
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.
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
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.
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)
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
A patch tool is used to generate a patch file in offline mode by using one or multiple patches.
Maintaining data consistency between the patch configuration/status tables and the host
based on the command information in the host
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
3.6.4 Implementation
This topic describes how to install and uninstall a patch, patch states, and patch state transition.
l
Patch states
The host software displays the following patch states for hot patches:
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)
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
Issue 01 (2009-02-10)
4-1
-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
Issue 01 (2009-02-10)
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
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+
+
10- 10+
+
Filler panel
Filler panel
FillerFpanel
Issue 01 (2009-02-10)
4-3
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)
SUBRACK-0
32A (4 PCS)
SUBRACK-2
50A (4 PCS)
(A7), A8,
(B7), and B8
SUBRACK-1
50A (4 PCS)
SUBRACK-0
50A (4 PCS)
Service
processing
cabinet
4-4
Issue 01 (2009-02-10)
RS 485
RS 485
SDM
SDM
SMM
SMM
OSTA 2.0 subrack
BASE bus
OMU
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-5
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.
Boolean
sensor
RS 485
SDM
SDM
SMM
SMM
OSTA 2.0 subrack
BASE bus
OMU
4-6
Issue 01 (2009-02-10)
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
Issue 01 (2009-02-10)
5-1
Hardware detection
The hardware detections implemented by boards are as follows:
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
5-2
Issue 01 (2009-02-10)
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
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.
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
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-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
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
Issue 01 (2009-02-10)
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.
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.
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-5
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
Issue 01 (2009-02-10)
Issue 01 (2009-02-10)
5-7
6 Time Synchronization
Time Synchronization
Issue 01 (2009-02-10)
6-1
6 Time Synchronization
6-2
Issue 01 (2009-02-10)
6 Time Synchronization
NetWork
NTP Server
NetWork
NTP Server
NetWork
NTP Server
4
NTP Client (OMU)
NTP Server
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
6 Time Synchronization
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
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.
Issue 01 (2009-02-10)
6 Time Synchronization
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
Layer 1
Layer 2
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-5
6 Time Synchronization
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)
6 Time Synchronization
NOTE
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
Issue 01 (2009-02-10)
7-1
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)
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.
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.
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-3
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.
Issue 01 (2009-02-10)
WAN/LAN
FTP/
FTAM
SWP
MSOFTX3000
Billing center
Network management
center
iGWB
MML
WAN/LAN
MML
OMU remote
maintenance terminal
Remote end
Issue 01 (2009-02-10)
7-5
Call control
module
CDR pool
iGWB
BC
WCCU
The charging system of the MSOFTX3000 consists of the WCCU, iGWB, BC, and
interconnection accessories.
l
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.
Issue 01 (2009-02-10)
CDR
pool of
the
WCCU
CDR
pool of
the
WCCU
Active
iGWB
Standby
iGWB
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
Generates and
transmits CDRs
FTP/
FTAM
BC
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.
Issue 01 (2009-02-10)
Whether
Final CDR
Is in ASN.1
Format
Whether
Final CDR
Is in Binary
Format
MOC CDR
(including
emergency
call CDRs)
MTC CDR
CFW CDR
MO_SMS
CDR
Issue 01 (2009-02-10)
7-9
CDR Type
Whether
Final CDR
Is in ASN.1
Format
Whether
Final CDR
Is in Binary
Format
MT_SMS
CDR
TRANSIT
CDR
GWO CDR
GWI CDR
7-10
Issue 01 (2009-02-10)
CDR Type
Whether
Final CDR
Is in ASN.1
Format
Whether
Final CDR
Is in Binary
Format
ROAM CDR
Location
Update
(VLR) CDR
CALL
ATTEMPT
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
CDR Type
Whether
Final CDR
Is in ASN.1
Format
Whether
Final CDR
Is in Binary
Format
MOI CDR
LCS CDR
Y
(including the
MT-LR, MOLR, and NILR)
7-12
Issue 01 (2009-02-10)
CDR Type
Whether
Final CDR
Is in ASN.1
Format
Whether
Final CDR
Is in Binary
Format
SS_ACT
CDR
CHECK_IM
EI CDR
QUERY_HL
R CDR
Issue 01 (2009-02-10)
7-13
CDR Type
Whether
Final CDR
Is in ASN.1
Format
Whether
Final CDR
Is in Binary
Format
TCAMEL
CDR
CommonEqu
ip CDR
7-14
Issue 01 (2009-02-10)
WCCU module
Host CDR pool
UDP
connection
on the Base
plane
WCCU module
iGWB
WAN/
LAN
BC
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-15
X3KM
Date
Original CDR file
Date
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)
The original CDR files are named in the format of b + a nine-digit serial number + .bil. For
example, b000000001.bil and b000000002.bil.
E:\backsave
X3KM
Second
Channel 1
X3KM
Date
Channel 1
Final CDR file
Date
Channel n
Channel n
Date
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
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.
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 n
Issue 01 (2009-02-10)
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).
Issue 01 (2009-02-10)
7-19
8 Final CDRs
Final CDRs
Issue 01 (2009-02-10)
8-1
8 Final CDRs
Mobile originated call CDR (MOC CDR) including emergency call CDR
8-2
Issue 01 (2009-02-10)