SoftX3000 Technical Manual-System Principle

Chapter 1 System Architecture ......................................................................
1-1
1.1 Hardware Composition ........................................................................... 1-1
1.1.1 Overview of Hardware Composition .............................................. 1-1
1.1.2 Service Processing Subsystem ..................................................... 1-1
1.1.3 Maintenance Management Subsystem.......................................... 1-2
1.1.4 Environment Monitoring Subsystem .............................................. 1-3
1.2 Logical Structure .................................................................................... 1-3
1.2.1 Interface Module ............................................................................ 1-5
1.2.2 System Support Module ................................................................. 1-5
1.2.3 Bottom-Layer Signaling Processing Module .................................. 1-6
1.2.4 Service Processing Module ........................................................... 1-6
1.2.5 Operation and Maintenance Module .............................................. 1-6
1.3 Buses ..................................................................................................... 1-7
1.3.1 Shared Resource Bus .................................................................... 1-7
1.3.2 Ethernet Bus .................................................................................. 1-8
1.3.3 H.110 bus....................................................................................... 1-10
1.3.4 Serial Port Bus ............................................................................... 1-12
Chapter 2 Processing Path for Signaling ...................................................... 2-1
2.1 Processing Path for Signaling over TDM ............................................... 2-1
2.1.1 Normal Processing Path for Signaling over TDM .......................... 2-1
2.1.2 Backup Processing Path of Signaling over TDM ........................... 2-2
2.2 Processing Path for ISUP/INAP over MTP3/M2UA ................................ 2-3
2.2.1 Uplink Path ..................................................................................... 2-3
2.2.2 Downlink Path ................................................................................ 2-4
2.3 Processing Path for ISUP/INAP over M3UA .......................................... 2-5
2.3.1 Uplink Path ..................................................................................... 2-5
2.3.2 Downlink Path ................................................................................ 2-6
2.4 Processing Path for MGCP/H.248 over UDP ......................................... 2-7
2.4.1 Uplink Path ..................................................................................... 2-8
2.4.2 Downlink Path ................................................................................ 2-9
2.5 Processing Path for H.323 over IP ......................................................... 2-10
2.5.1 Uplink Path ..................................................................................... 2-10
2.5.2 Downlink Path ................................................................................ 2-13
2.6 Processing Path for SIP over UDP......................................................... 2-15
2.6.1 Uplink Path ..................................................................................... 2-15
2.6.2 Downlink Path ................................................................................ 2-17
2.7 Processing Path for DSS1 over IUA ....................................................... 2-18
2.7.1 Uplink Path ..................................................................................... 2-18
2.7.2 Downlink Path ................................................................................ 2-19
2.8 Processing Path for V5.2 over V5UA ..................................................... 2-20
2.8.1 Uplink Path ..................................................................................... 2-20
2.8.2 Downlink Path ................................................................................ 2-21
Chapter 3 Operation and Maintenance Principle .......................................... 3-1
3.1 Hardware Architecture of Terminal System ............................................ 3-1
3.1.1 BAM ............................................................................................... 3-1
3.1.2 iGWB .............................................................................................. 3-2
3.1.3 Emergency Workstation ................................................................. 3-2
3.1.4 Workstation .................................................................................... 3-2
3.2 Software Architecture of Terminal System ............................................. 3-2
3.2.1 BAM Software ................................................................................ 3-4
3.2.2 Operation and Maintenance Software ........................................... 3-9
3.2.3 Communication Gateway Software................................................ 3-11
3.3 Security Management ............................................................................ 3-12
3.3.1 Command Group ........................................................................... 3-13
3.3.2 Workstation Management .............................................................. 3-13
3.3.3 Account Management .................................................................... 3-14
3.3.4 Specifying Login Time .................................................................... 3-14
3.3.5 Locking the Client .......................................................................... 3-14
3.4 Data Storage .......................................................................................... 3-14
3.4.1 Storage of BAM Data ..................................................................... 3-14
3.4.2 Storage of Host Data ..................................................................... 3-14
3.4.3 Storage of Supplementary Services .............................................. 3-15
3.5 Data Loading and Data Operation .......................................................... 3-16
3.5.1 Data Loading .................................................................................. 3-16
3.5.2 Data Operation ............................................................................... 3-20
3.6 Software Patch Management ................................................................. 3-22
3.6.1 Basic Concepts .............................................................................. 3-22
3.6.2 Features of Software Patch ........................................................... 3-22
3.6.3 Architecture of Software Patch ...................................................... 3-23
3.6.4 Implementation of Software Patch ................................................. 3-24
Chapter 4 Charging System ............................................................................ 4-1
4.1 Basic Concepts ...................................................................................... 4-1
4.1.1 SoftX3000 Charging ....................................................................... 4-1
4.1.2 Offline Billing or Online Billing ........................................................ 4-1
4.1.3 Bill Type ......................................................................................... 4-2
4.2 Architecture of Charging System............................................................ 4-4
4.2.1 Logical Architecture of Charging System ....................................... 4-4
4.2.2 Functioning Process of Charging System ...................................... 4-5
4.3 Bill Storage ............................................................................................. 4-8
4.3.1 Bill Storage Directory ..................................................................... 4-9
4.3.2 Storage of Original Bills ................................................................. 4-9
4.3.3 Storage of Final Bills ...................................................................... 4-11
Chapter 5 Alarm System ................................................................................. 5-1
5.1 Overview of Alarm System ..................................................................... 5-1
5.2 Structure of Alarm System ..................................................................... 5-1
5.3 Alarm Categories and Alarm Levels ....................................................... 5-2
5.3.1 Alarm Categories ........................................................................... 5-2
5.3.2 Alarm Levels .................................................................................. 5-3
5.4 Alarm Box and Alarm Console ............................................................... 5-3
5.4.1 Alarm Box ...................................................................................... 5-3
5.4.2 Alarm Console ............................................................................... 5-4
5.5 Alarm Reporting Paths ........................................................................... 5-5
5.5.1 Hardware Alarm Reporting Paths .................................................. 5-5
5.5.2 Software Alarm Reporting Paths .................................................... 5-8
Chapter 6 Environment Monitoring System .................................................. 6-1
6.1 Power Supply System ............................................................................ 6-1
6.1.1 Power Introduction Module ............................................................ 6-1
6.1.2 Power Distribution Module ............................................................. 6-2
6.2 Power Supply Monitoring ....................................................................... 6-4
6.2.1 Monitoring PDF .............................................................................. 6-4
6.2.2 Monitoring Power Supply of OSTA frame ...................................... 6-5
6.3 Fan Monitoring ....................................................................................... 6-5
6.4 Equipment Room Environment monitoring............................................. 6-6
Chapter 7 Clock Synchronization System ..................................................... 7-1
7.1 Introduction............................................................................................. 7-1
7.1.1 Features ......................................................................................... 7-1
7.1.2 Technical Specifications ................................................................ 7-1
7.2 Overall Structure of Clock System ......................................................... 7-3
7.3 Implementation of Clock System Synchronization ................................. 7-5
Appendix A Format of Final Bills ................................................................... A-1
A.1 Fixed IN bill ............................................................................................ A-1
A.2 Fixed Ordinary Detail Bill Format ........................................................... A-7
A.3 Fixed Network Meter Table Bill Format .................................................. A-16
A.4 Fixed Network Meter Table Statistics Bill ( statisticsMeterBill) .............. A-20
A.5 Fixed Network Trunk Occupation Duration Statistics Bill ....................... A-22
A.6 Fixed Network Statistics Bill of Free Calls ............................................. A-23
A.7 Supplementary Service Bill .................................................................... A-25
Appendix B Acronyms and Abbreviations .................................................... B-1
Index .................................................................................................................
HUAWEI
U-SYS SoftX3000 SoftSwitch System

Technical Manual – System Principle
V300R003
Huawei Technologies Proprietary

U-SYS SoftX3000 SoftSwitch System
Technical Manual
Volume System Principle
Manual Version T2-010259-20050608-C-3.32
Product Version V300R003
BOM 31026659
Huawei Technologies Co., Ltd. provides customers with comprehensive technical support
and service. Please feel free to contact our local office or company headquarters.
Huawei Technologies Co., Ltd.
Address: Administration Building, Huawei Technologies Co., Ltd.,
Bantian, Longgang District, Shenzhen, P. R. China
Postal Code: 518129
Website: http://www.huawei.com
Email: support@huawei.com

Copyright © 2005 Huawei Technologies Co., Ltd.
All Rights Reserved
No part of this manual may be reproduced or transmitted in any form or by any

means without prior written consent of Huawei Technologies Co., Ltd.
Trademarks
, HUAWEI, C&C08, EAST8000, HONET, , ViewPoint, INtess, ETS, DMC,

TELLIN, InfoLink, Netkey, Quidway, SYNLOCK, Radium, M900/M1800,
TELESIGHT, Quidview, Musa, Airbridge, Tellwin, Inmedia, VRP, DOPRA,
iTELLIN, HUAWEI OptiX, C&C08 iNET, NETENGINE, OptiX, iSite, U-SYS, iMUSE,
OpenEye, Lansway, SmartAX, infoX, and TopEng are trademarks of Huawei
Technologies Co., Ltd.
All other trademarks and trade names mentioned in this manual are the property of
their respective holders.
Notice
The information in this manual is subject to change without notice. Every effort has
been made in the preparation of this manual to ensure accuracy of the contents,
but all statements, information, and recommendations in this manual do not
constitute the warranty of any kind, express or implied.

About This Manual
Release Notes
The manual applies to U-SYS SoftX3000 SoftSwitch System V300R003 (hereinafter

referred to as SoftX3000).
Related Manuals
The related manuals are listed in the following table.
Manual Content
U-SYS SoftX3000 SoftSwitch It provides an overall introduction to the
System Technical SoftX3000, including product features,
Manual-System Description applications, and technical specifications.
It details on the hardware architecture,

U-SYS SoftX3000 SoftSwitch
component interworking mechanism, and
System Technical
subsystems of alarm, billing, and clock in the
Manual-System Principle
SoftX3000.
It details the features and technical
U-SYS SoftX3000 SoftSwitch specifications of the hardware components of
System Hardware Description the SoftX3000, including cabinets, frames,
Manual boards, cables, and cabinet internal
components.
It covers various services and functions
supported by the SoftX3000, including voice
U-SYS SoftX3000 SoftSwitch services, supplementary services, IP Centrex
System Technical services, multi-media services, value added
Manual–Services and Features services, dual homing functions, charging
functions, IPTN functions, remote network
access functions, and so on.
It details the installation procedure of the
SoftX3000 hardware components, and matters
System Hardware Installation
needing attention during the installation
Manual
process.
It covers the detailed procedure of installing the

U-SYS SoftX3000 SoftSwitch SoftX3000 software, including BAM server,
System Software Installation emergency workstation, and client, focusing on
Manual the key points that might cause installation
failure.
U-SYS SoftX3000 SoftSwitch It guides the maintenance engineers to perform

System Routine Maintenance daily maintenance, monthly maintenance, and
Guide yearly maintenance tasks on the SoftX3000.

Manual Content
It guides the maintenance engineers to perform
recovery operations in the case of emergencies,
System Emergency
such as congestion of global service, AMG, and
Maintenance Manual
TMG, and failure of host and BAM.
It guides the maintenance engineers on how to
U-SYS SoftX3000 SoftSwitch replace hardware components of the
System Part Replacement Guide SoftX3000, such as boards, fan frame, LAN
Switch, and hard disk.
It guides the engineers how to configure various
data in the SoftX3000, including configuration
System Operation
steps, preparations, database table referencing
Manual-Configuration Guide
relationships, and command parameters.
It guides the engineers how to configure various

data in the SoftX3000, including networking
System Operation
example, configuration script, key parameters
Manual-Configuration Examples
and debugging guidance.
It guides the engineers how to work on
System Operation
performance measurement tasks and analyze
Manual-Performance
measurement results.
Measurement
It guides the engineers how to use the GUI on

U-SYS SoftX3000 SoftSwitch various clients of the SoftX3000, including
System Operation Manual-GUI operations on menus and navigation tree. In
Guide addition, it introduces the operations on
TableBrowse.
It guides the engineers how to install and use
the software related to the BAM, including
remote maintenance software, anti-virus
System BAM User Manual
software, system customized software, and so
on.
It elaborates on the functioning principle of the

U-SYS iGateway Bill User
iGateway Bill. Also, it teaches you on how to
Manual
install, maintain, and operate the product.
Organization
This manual focuses on the systemic principles and functionalities of the SoftX3000. It
introduces the logical structure, buses, signaling flows and paths, component
interworking mechanism, and subsystems of alarm, billing, and clock in the
SoftX3000.
There are seven chapters and two appendixes in the manual.

z Chapter 1 System Architecture profiles hardware architecture of the
SoftX3000 as well as the important components.

z Chapter 2 Processing Path for Signaling details processing path of TDM and
IP based signaling in the SoftX3000.
z Chapter 3 Operation and Maintenance Principle presents the hardware and
software architecture of maintenance management subsystem. The chapter also
describes the security management, data management, and software patch
management.
z Chapter 4 Charging System focuses on the charging and billing process and
mechanism in SoftX3000.
z Chapter 5 Alarm System details on alarm system architecture, the functions
and features of alarm box and alarm console, and alarm reporting path.
z Chapter 6 Environment Monitoring System details the monitoring principle
and process of power supply system, fan, and the equipment room.
z Chapter 7 Clock Synchronization System provides more information about
the features, specifications, and synchronization principle of the clock system in
SoftX3000.
z Appendix A Format of Original Bills lists the different formats of original bills.
z Appendix B Acronyms and Abbreviations collects the definitions of terms and
acronyms that are used in this manual.
Intended Readers
The manual is intended for the following readers:

z NGN network planning experts
z NGN network administrators
z NGN system engineers
Conventions
The manual uses the following conventions:
I. General conventions
Convention Description
Arial Normal paragraphs are in Arial.
Boldface Headings are in Boldface.
Courier New Terminal Display is in Courier New.
II. Symbols
Eye-catching symbols are also used in the manual to highlight the points worthy of
special attention during the operation. They are defined as follows:

Caution: Means reader be extremely careful during the operation.
Note: Means a complementary description.

U-SYS SoftX3000 SoftSwitch System Table of Contents
Table of Contents
Chapter 1 System Architecture.................................................................................................... 1-1

1.1 Hardware Composition ...................................................................................................... 1-1
1.1.1 Overview of Hardware Composition........................................................................ 1-1
1.1.2 Service Processing Subsystem............................................................................... 1-1
1.1.3 Maintenance Management Subsystem................................................................... 1-2
1.1.4 Environment Monitoring Subsystem ....................................................................... 1-3
1.2 Logical Structure ................................................................................................................ 1-3
1.2.1 Interface Module...................................................................................................... 1-5
1.2.2 System Support Module.......................................................................................... 1-5
1.2.3 Bottom-Layer Signaling Processing Module ........................................................... 1-6
1.2.4 Service Processing Module..................................................................................... 1-6
1.2.5 Operation and Maintenance Module ....................................................................... 1-6
1.3 Buses ................................................................................................................................. 1-7
1.3.1 Shared Resource Bus ............................................................................................. 1-7
1.3.2 Ethernet Bus............................................................................................................ 1-8
1.3.3 H.110 bus .............................................................................................................. 1-10
1.3.4 Serial Port Bus ...................................................................................................... 1-12
Chapter 2 Processing Path for Signaling ................................................................................... 2-1

2.1 Processing Path for Signaling over TDM........................................................................... 2-1
2.1.1 Normal Processing Path for Signaling over TDM ................................................... 2-1
2.1.2 Backup Processing Path of Signaling over TDM .................................................... 2-2
2.2 Processing Path for ISUP/INAP over MTP3/M2UA........................................................... 2-3
2.2.1 Uplink Path .............................................................................................................. 2-3
2.2.2 Downlink Path ......................................................................................................... 2-4
2.3 Processing Path for ISUP/INAP over M3UA ..................................................................... 2-5
2.3.1 Uplink Path .............................................................................................................. 2-5
2.3.2 Downlink Path ......................................................................................................... 2-6
2.4 Processing Path for MGCP/H.248 over UDP .................................................................... 2-7
2.4.1 Uplink Path .............................................................................................................. 2-8
2.4.2 Downlink Path ......................................................................................................... 2-9
2.5 Processing Path for H.323 over IP .................................................................................. 2-10
2.5.1 Uplink Path ............................................................................................................ 2-10
2.5.2 Downlink Path ....................................................................................................... 2-13
2.6 Processing Path for SIP over UDP .................................................................................. 2-15
2.6.1 Uplink Path ............................................................................................................ 2-15
2.6.2 Downlink Path ....................................................................................................... 2-17
2.7 Processing Path for DSS1 over IUA ................................................................................ 2-18
i
2.7.1 Uplink Path ............................................................................................................ 2-18

2.7.2 Downlink Path ....................................................................................................... 2-19
2.8 Processing Path for V5.2 over V5UA .............................................................................. 2-20
2.8.1 Uplink Path ............................................................................................................ 2-20
2.8.2 Downlink Path ....................................................................................................... 2-21
Chapter 3 Operation and Maintenance Principle ....................................................................... 3-1

3.1 Hardware Architecture of Terminal System....................................................................... 3-1
3.1.1 BAM......................................................................................................................... 3-1
3.1.2 iGWB ....................................................................................................................... 3-2
3.1.3 Emergency Workstation .......................................................................................... 3-2
3.1.4 Workstation ............................................................................................................. 3-2
3.2 Software Architecture of Terminal System ........................................................................ 3-2
3.2.1 BAM Software ......................................................................................................... 3-4
3.2.2 Operation and Maintenance Software .................................................................... 3-9
3.2.3 Communication Gateway Software....................................................................... 3-11
3.3 Security Management...................................................................................................... 3-12
3.3.1 Command Group................................................................................................... 3-13
3.3.2 Workstation Management ..................................................................................... 3-13
3.3.3 Account Management ........................................................................................... 3-14
3.3.4 Specifying Login Time........................................................................................... 3-14
3.3.5 Locking the Client.................................................................................................. 3-14
3.4 Data Storage.................................................................................................................... 3-14
3.4.1 Storage of BAM Data ............................................................................................ 3-14
3.4.2 Storage of Host Data............................................................................................. 3-14
3.4.3 Storage of Supplementary Services...................................................................... 3-15
3.5 Data Loading and Data Operation ................................................................................... 3-16
3.5.1 Data Loading ......................................................................................................... 3-16
3.5.2 Data Operation ...................................................................................................... 3-20
3.6 Software Patch Management .......................................................................................... 3-22
3.6.1 Basic Concepts ..................................................................................................... 3-22
3.6.2 Features of Software Patch................................................................................... 3-22
3.6.3 Architecture of Software Patch.............................................................................. 3-23
3.6.4 Implementation of Software Patch ........................................................................ 3-24
Chapter 4 Charging System ......................................................................................................... 4-1

4.1 Basic Concepts .................................................................................................................. 4-1
4.1.1 SoftX3000 Charging................................................................................................ 4-1
4.1.2 Offline Billing or Online Billing ................................................................................. 4-1
4.1.3 Bill Type................................................................................................................... 4-2
4.2 Architecture of Charging System ....................................................................................... 4-4
4.2.1 Logical Architecture of Charging System................................................................ 4-4
4.2.2 Functioning Process of Charging System............................................................... 4-5
4.3 Bill Storage......................................................................................................................... 4-8
ii
4.3.1 Bill Storage Directory .............................................................................................. 4-9

4.3.2 Storage of Original Bills........................................................................................... 4-9
4.3.3 Storage of Final Bills ............................................................................................. 4-11
Chapter 5 Alarm System............................................................................................................... 5-1

5.1 Overview of Alarm System ................................................................................................ 5-1
5.2 Structure of Alarm System................................................................................................. 5-1
5.3 Alarm Categories and Alarm Levels .................................................................................. 5-2
5.3.1 Alarm Categories..................................................................................................... 5-2
5.3.2 Alarm Levels............................................................................................................ 5-3
5.4 Alarm Box and Alarm Console........................................................................................... 5-3
5.4.1 Alarm Box................................................................................................................ 5-3
5.4.2 Alarm Console......................................................................................................... 5-4
5.5 Alarm Reporting Paths....................................................................................................... 5-5
5.5.1 Hardware Alarm Reporting Paths ........................................................................... 5-5
5.5.2 Software Alarm Reporting Paths............................................................................. 5-8
Chapter 6 Environment Monitoring System ............................................................................... 6-1

6.1 Power Supply System........................................................................................................ 6-1
6.1.1 Power Introduction Module ..................................................................................... 6-1
6.1.2 Power Distribution Module ...................................................................................... 6-2
6.2 Power Supply Monitoring................................................................................................... 6-4
6.2.1 Monitoring PDF ....................................................................................................... 6-4
6.2.2 Monitoring Power Supply of OSTA frame ............................................................... 6-5
6.3 Fan Monitoring ................................................................................................................... 6-5
6.4 Equipment Room Environment monitoring........................................................................ 6-6
Chapter 7 Clock Synchronization System .................................................................................. 7-1

7.1 Introduction ........................................................................................................................ 7-1
7.1.1 Features .................................................................................................................. 7-1
7.1.2 Technical Specifications.......................................................................................... 7-1
7.2 Overall Structure of Clock System..................................................................................... 7-3
7.3 Implementation of Clock System Synchronization ............................................................ 7-5
Appendix A Format of Final Bills.................................................................................................A-1

A.1 Fixed IN bill........................................................................................................................A-1
A.2 Fixed Ordinary Detail Bill Format ......................................................................................A-7
A.3 Fixed Network Meter Table Bill Format...........................................................................A-16
A.4 Fixed Network Meter Table Statistics Bill (statisticsMeterBill) ........................................A-20
A.5 Fixed Network Trunk Occupation Duration Statistics Bill ................................................A-22
A.6 Fixed Network Statistics Bill of Free Calls.......................................................................A-23
A.7 Supplementary Service Bill .............................................................................................A-25
iii
Appendix B Acronyms and Abbreviations .................................................................................B-1
Index ................................................................................................................................................ i-1
iv
U-SYS SoftX3000 SoftSwitch System Chapter 1 System Architecture
Chapter 1 System Architecture
1.1 Hardware Composition

1.1.1 Overview of Hardware Composition
Figure 1-1 shows the physical structure and among components in the SoftX3000.
FE
LAN Switch 2 IP network
FE
To the billing
LAN Switch 3 FE FE center
FE
To the billing
Active iGWB
Frame 0 center
LAN Switch 0
3×FE
Standby iGWB
Frame 1
LAN Switch 1
BAM
Background
LAN Switch
To NMS
Emergency
Frame 17 Workstation
WS WS WS
Host
FE: Fast Ethernet interface 3×FE: Three FE cables WS: Workstation

Figure 1-1 Physical structure of SoftX3000
The SoftX3000 hardware architecture is composed of three subsystems:

z Service processing subsystem
z Maintenance management subsystem
z Environment monitoring subsystem
The following content will show you the details of the subsystems.
1.1.2 Service Processing Subsystem
The service processing subsystem, or host, foreground, is the core of the SoftX3000. It
is composed of OSTA frames and connection devices. It implements functions of
service processing and resource management.
1-1
I. Inter-Device Communication
The communication of the SoftX3000 service processing subsystem involves the

following three parts:
z The OSTA frames communicate with each other through two LAN Switches (LAN
Switch in the plane 0 and LAN Switch in the plane 1). Each frame is connected to
both LAN Switches through Ethernet cables respectively.
z When the host and the background communicate, the OSTA frames and BAM,
and the OSTA frames and iGWB communicate through two LAN Switches (LAN
Switch in the plane 0 and LAN Switch in the plane 1). The BAM and the iGWB are
connected to both LAN Switches through Ethernet cables respectively.
z The OSTA frames communicate with exterior network devices from basic frame 0
and basic frame 1 through LAN Switch 2 and LAN Switch 3.
II. System Capacity Feature
In an actual deployment, the capacity of the system depends on the number of OSTA
frames ranging from 1 to 18, which fully meets the requirement of smooth expansion.
1.1.3 Maintenance Management Subsystem
The maintenance management subsystem, or background, is composed of the

following items:
z BAM
z Emergency workstation
z Workstation
z iGWB
z Connection devices
It implements functions of operation maintenance, and bill management. The
communication of the maintenance management subsystem covers the following four
aspects:
z The BAM, the iGWB, and the emergency workstation communicate with service
processing subsystem through two LAN Switches (LAN Switch in the plane 0 and
LAN Switch in the plane 1).The BAM, the iGWB and the emergency workstation
connect the two LAN Switches through Ethernet cables. When the BAM works
normally, the FE cables connecting the emergency workstation are disconnected
from the two LAN Switches (shown as broken lines in Figure 1-1). When the
communication between the BAM and the host is abnormal, the FE cables
connecting the emergency workstation will be plugged in the two LAN Switches.
z The BAM, the active/standby iGWB, and the emergency workstation are
connected to the two LAN Switches with an Ethernet cable respectively. The WS
communicate with the BAM and the iGWB in TCP/IP in client/server mode. The
1-2
network management interface is provided to external devices through this LAN

Switch.
z When communicating with the billing center, the active and standby iGWBs are
connected to an Ethernet cable respectively providing FE ports to external
devices.
z The emergency workstation regularly backs up the data of BAM. Once the BAM is
faulty, the emergency workstation takes the place of the BAM after you connect
the Ethernet cables to both LAN Switches in the planes 0 and 1 respectively.
1.1.4 Environment Monitoring Subsystem
The environment monitoring subsystem includes three modules:

z Power supply monitoring module
z Fan monitoring module (of every service processing subrack)
z Monitoring module (in the power distribution subrack of each cabinet)
It is designed to ensure that the SoftX3000 works in a normal environment.
1.2 Logical Structure

Figure 1-2 shows the logical structure of the SoftX3000.
1-3
System support module
FE interface FE interface Equipment Database

unit management unit processing unit
BITS interface Ethernet bus/Shared resource bus
Broadband Multimedia
Clock signaling
signaling
interface unit
processing unit processing unit Internal
iGWB 0
PCI bus
2MHz
clock
HW
MTP2 L
E1 interface iGWB 1
processing unit Service processing unit A
module
N
E1 interface S
Interface module Signaling processing module Service processing module w Emergency
i workstation
Basic frame t
c
BAM
h
System support module
Device WS WS
management unit
Operation and
maintenance module
Ethernet bus/Shared resource bus
Broadband Multimedia
signaling signaling
processing unit processing unit
Internal
PCI bus
HW
MTP2
E1 interface E1 interface processing
module Service processing unit
unit
Interface module Signaling processing module Service processing module
Expansion frame n
Figure 1-2 System logical architecture
Logically, the SoftX3000 is composed of five modules:

z Interface module
z System support module
z Bottom-layer signaling processing module
z Service processing module
z Operation and maintenance (OAM) module
1-4
Note:
z For detailed information about racks, cabinets, frames, boards, and cables, refer to
U-SYS SoftX3000 SoftSwitch System Hardware Description Manual.
z For information about the board with embedded media resource server (MRS), also
refer to U-SYS SoftX3000 SoftSwitch System Hardware Description Manual.
1.2.1 Interface Module
The interface module provides physical interfaces for networking, including the
narrowband interface unit (E1_Pool interface unit, EPII), the broadband interface unit
(IP forward module, IFMI), the back insert FE interface unit (BFII) and the clock
interface unit (CKII)
z The EPII implements E1/T1 framing and line interface functions, and interworks
with the signaling processing module through internal highway (HW).
z The IFMI establishes communication with external devices such as connecting IP
network through the 100M bit/s Ethernet interface provided by BFII. The IFMI
converges the IP signaling streams, and forwards the following types of messages
to broadband signaling gateway (BSGI) or multimedia signaling gateway unit
(MSGI) through the Ethernet bus according to specific strategy: User Datagram
Protocol (UDP), Transmission Control Protocol (TCP), and Stream Control
Transmission Protocol (SCTP).
z The CKII provides building integrated timing supply (BITS) and 2M Hz clock
interface, which satisfies the clock requirement during narrowband networking of
SoftX3000 devices.
1.2.2 System Support Module
The system support module implements such functions as software and data loading,
device management and maintenance and inter-board communications. It comprises
system management unit (SMUI), system interface unit (SIUI), and hot-swap and
control Unit (HSCI).
z As the main control board of a frame, the SMUI implements program loading and
control for all devices in the system, data configuration and working status control
functions.
z The HSCI implements bridge connection of left shared resource bus with right one,
board hot swap control and intra-frame Ethernet bus exchange.
1-5
1.2.3 Bottom-Layer Signaling Processing Module
This module provides signaling protocol processing functions. It contains the MTP2
processing unit of the Fixed Calling Control and Signaling process Unit (FCSU),
Broadband Signaling Gateway (BSGI) and Multimedia Signaling Gateway Unit (MSGI).
z The MTP2 processing unit of the FCSU implements processing of messages on
SS7 signaling MTP2 layer over narrowband E1 and communicates with the Fixed
Calling Control Unit (FCCU) and FCSU through the internal Peripheral
Component Interconnect (PCI) bus.
z The BSGI codes/decodes the Media Gateway Control Protocol (MGCP),
H.248/MeGaCo protocol (H.248), UDP, SCTP, SS7 MTP2-User Adaptation Layer
(M2UA), SS7 MTP3-User Adaptation Layer (M3UA), ISDN User Adaptation Layer
(IUA), V5 User Adaptation Layer (V5UA) and distributes the messages to
FCCU/FCSU for processing through the Ethernet bus.
z After coding the UDP, TCP and multimedia signaling protocol, the MSGI
distributes the messages to FCCU/FCSU for processing through the Ethernet bus.
The multimedia signaling protocol includes Session Initiated Protocol (SIP), H.323
Registration, Admission and Status (RAS) and H.323 CALL Signaling (based on
the Q.931/Q.932 of ISDN with Q.931 being the most important).
1.2.4 Service Processing Module
The service processing module includes FCCU, FCSU and central database board
(CDBI), .
z The FCCU implements processing of H.323, SIP, MGCP, H.248, R2, DSS1), V5
signaling messages and those above MTP3 layer, such as MTP3, INAP and
Integrated Services Digital Network User Part (ISUP) messages, and provides
charging and SoftX3000 bill storage functions.
z In addition to the functions of the FCCU, the FCSU can receive and process the
MTP2 messages sent from the EPII through the internal HW.
z As the system central database board, the CDBI stores centralized resources
(inter-office trunk resources, resource capability status, subscriber data and IP
Centrex data), and provides call resources query service for the service
processing units.
1.2.5 Operation and Maintenance Module
The operation and maintenance module is composed of BAM, workstations, iGWB,

LAN Switches and emergency workstations. It is responsible for the system
management and maintenance and bill processing. The two LAN Switches
interconnect the devices among multiple frames.
1-6
1.3 Buses
Each OSTA frame contains four types of buses: shared resource bus, Ethernet bus,
H.110 bus, and serial port bus, as shown in Figure 1-3. All the functions of the
SoftX3000, including board communication, program and data loading and alarm
reporting can be implemented by these buses.
S H S H
B B B B B B I S I S B B B B B B
BB: Back board
B B B B B B U C U C B B B B B B
I I I I
Serial port bus

H.110 bus
Shared resource bus A Shared resource bus B
Ethernet bus A
Ethernet bus B
S S A
F F F F F F M M F F F F F F L
B B B B B B U U B B B B B B
U
I I I
Figure 1-3 Buses in a frame
1.3.1 Shared Resource Bus
I. Functions
Shared resource bus enables SMUIs to load, manage and maintain all loadable boards
in the same frame, such as IFMI/BSGI/FCCU/FCSU/CDBI/MRCA/MSGI.
II. Implementation
As shown in Figure 1-4, there are 2 shared resource buses, namely A and B, in one
frame. The bandwidth of each shared resource bus is 2G bit/s. The states and
resources of shared resource buses are arbitrated and managed by the SMUI.
B B S H S H
F F I S I S
I I U C U C
I I I I I I
S S
F F F F F F M M F F F F F F
I I
Figure 1-4 Shared resource buses
1-7
The SMUI in the slot 6 manages the front boards in the left half of the frame through the
shared resource bus A. The SMUI in the slot 8 manages other front boards except ALUI
and UPWR in the right half of the frame through the shared resource bus B. The HSCIs
in the slots 7 and 9 are connected respectively to the shared resource buses through
the internal PCI bus, and thus the shared resource buses are interconnected.
Therefore, the SMUI in the slot 6 makes full use of the HSCI in the slot 9 and the shared
resource bus B to manage front boards in the right half of the frame; the SMUI in the
slot 8 makes full use of the HSCI in the slot 7 and the shared resource bus A to manage
front boards in the left half of the frame.
1.3.2 Ethernet Bus
I. Functions
The Media Resource Control Unit (MRCA), FCSU, FCCU, BSGI, MSGI, IFMI, SMUI,
and CDBI in the OSTA frames act as the communication channel of inter-board service
through the Ethernet bus, ensuring that the system processing flows are uniform and
smooth.
II. Implementation
As shown in Figure 1-5, there are 2 Ethernet buses, namely A and B, in one frame. The
bandwidth of each Ethernet bus is 100 Mbit/s. Each Ethernet bus is connected to the
HSCIs in the slots 7 and 9 respectively.
Network cables
S H S H
I S I S
U C U C
I I I I
Ethernet bus A
Ethernet bus B
S S
I I
Figure 1-5 Ethernet buses
Note:
SMUIs are not directly connected to an Ethernet bus. Instead, the network ports of the
two SIUIs are interconnected to the two HSCIs through four external Ethernet cables,
achieving Ethernet dual planes.
1-8
III. Ethernet Dual Planes
As shown in Figure 1-6, frames are interconnected to core LAN switches in the
integrated configuration cabinet through FE interfaces on HSCIs. The binding mode
improves the reliability and communication bandwidth of physical connections,
achieving dual planes. The core LAN Switches are interconnected through GE
externally, achieving cross planes.
Internal External External

S network cable S network cable H network cable
I S LAN Switch
M
U U C
I I I
3×FE
S H
S
I S LAN Switch
M
U C
U External
External
Internal
I I network cable
I network cable network cable
OSTA frame
Figure 1-6 Ethernet dual planes
Note:
z The communication structure of dual planes ensures that the system configures two
IP addresses for each SMUI board, one of which is in the network segment of
“172.20.xxx.xxx”, and the other is in the network segment of “172.30.xxx.xxx” during
loading or after loading.
z During loading, The SMUI uses the temporary IP address. The two SMUIs have
different IP addresses. The IP addresses of the SMUI in slot 6 are 172.20.frame
number.100 and 172.30.frame number.100. The IP addresses of the SMUI in slot 8
are 172.20.frame number.101 and 172.30.frame number.101.
z After loading, the system will re-configure the IP address of the SMUI. The two
SMUI have the same IP address: 172.20.200.module number and
172.30.200.module number.
1) Normal communication path

Normally there are two paths for a processing board A in a frame A to communicate with
a processing board C in a frame B, as shown in Figure 1-7.
1-9
External
H network External H
Processing
Ethernet bus
Processing
network cable Ethernet bus
board C
cable
board A
S LAN Switch 0 S
C C
I I
0 0
Ethernet bus External Ethernet bus

H network External H
S cable network cable S
C LAN Switch 1
C
I I
OSTA frame A 1 1 OSTA frame B
Figure 1-7 Normal communication path
2) Cross communication path

In case that the HSCI 1 in the frame A or the HSCI 0 in the frame B is faulty, the
communication path for the processing boards A and C is shown in Figure 1-8
External
H network H
Processing
Processing
board C
cable S
board A
LAN Switch 0
C C
Etnernet bus
I I
0 0
3 x FE
Etnernet bus
H External H
S network cable S
C LAN Switch 1 C
I I
1 1
OSTA frame A OSTA frame B
Figure 1-8 Cross communication path
1.3.3 H.110 bus
I. Functions
As shown in Figure 1-9, there is one H.110 bus in one frame. The bus provides a
switching capability of 4096 time slots. The H.110 bus provides the following functions:
z Service changeover between active and standby FCSUs
z Transmission channel for reference clock signals inside the frame
1-10
S H S H
B B B B B B I S I S B B B B B B
B B B B B B U C U C B B B B B B
I I I I
H.110 bus
HW HW HW HW HW HW HW HW HW HW HW HW
S S
I I
Figure 1-9 H.110 bus
II. Service Backup Function During a Front Board Switchover Process
As shown in Figure 1-10, the path for processing narrowband SS7 signaling is E1 ->
EPII 0 -> Internal HW -> FCSU 0.
In the event of FCSU switchover or failure, the processing path for communication is E1
-> EPII 0 -> H.110 bus -> EPII 1 -> internal HW -> FCSU 1.
Caution:
The H.110 bus can implement the service backup function only when FCSUs switch
over. Because E1 is invariably configured on EPIIs, EPII switchover will cause
interruption of trunk circuits and interruption of signaling links.
8 x E1
EPII EPII1
H.110 bus
Internal HW Internal HW
FCSU0 FCSU1
Figure 1-10 FCSU switchover principle
1-11
1.3.4 Serial Port Bus
As shown in Figure 1-11, SMUIs manage, through the serial port bus, the boards that
are not connected to a shared resource bus in a service processing frame. Applicable
boards include CKIIs, EPIIs and ALUIs. The baud rate of the serial port bus is
38.4 kbit/s.
Slave nodes of master/slave serial ports also include monitor board of power
distribution box and fan box. The baud rate for the monitor board to communicate with
the master node (SMUI) is 9600 bit/s.
SMUIs take advantage of shared resource bus and corresponding front boards to
manage back boards without a processor, such as SIUIs, HSCIs, EPIIs and MRIA.
SMUIs take advantage of serial port bus, ALUI and two serial port wires embedded in
the backplane to manage UPWRs.
S S
B B B B B B I I B B B B B B
I I
Serial port bus
S S A
M M L
U U U
I I I
Figure 1-11 Serial port bus
1-12
U-SYS SoftX3000 SoftSwitch System Chapter 2 Processing Path for Signaling
Chapter 2 Processing Path for Signaling
2.1 Processing Path for Signaling over TDM

2.1.1 Normal Processing Path for Signaling over TDM
The normal processing path for signaling over Time Division Multiplex (TDM) is
illustrated in Figure 2-1.
FE FE
Core LAN Switch Core LAN Switch

E1
E E S H S H
P P I S I S
I I U C U C
I I I I I I
H.110 bus
Ethernet bus
HW
F F S S F F
C C M M C C
S S U U C C
U U I I U U Frame A
Figure 2-1 Normal processing path of signaling over TDM
1) The E1 interface of an EPII provides a TDM Pulse Code Modulation (PCM)

interface to access standard 64 kbit/s or 2 Mbit/s Signaling System No. 7 (SS7)
signaling links.
2) The EPII processes message transfer part layer 1 (MTP1) messages, extracts
signaling time slots, and transmits them to the FCSU in direct pin-to-pin
transmission.
3) The FCSU processes both Message Transfer Part Layer 2 (MTP2) and Message
Transfer Part Layer 3 (MTP3) messages. The FCSU analyzes the destination
point code (DPC) carried by a message. If the message is destined to the board
itself, the WCSU dispatches, based on the service indicator (SI), the message to
the service layer of the board itself to process the user layer message. Otherwise,
the FCSU transfers the user layer message to a designated FCCU/WCSU for
2-1
further processing, based on the network indicator (NI), originating point code
(OPC), DPC, and circuit identification code (CIC) carried in the message.
Note:
If the destination BSGI and FCCU/FCSU are resident in a different frame, the dispatch
path passes the HSCI and core LAN Switch in the local frame, the HSCI in the
destination frame with the destination FCCU/FCSU, and the destination BSGI and
destination FCCU/FCSU.
2.1.2 Backup Processing Path of Signaling over TDM
In the event of a failure occurrence at the FCSU 0 which corresponds to the EPII 0
providing E1 interface, the processing path for signaling over TDM is illustrated in
Figure 2-2.
FE FE
Core LAN Switch Core LAN Switch

E1
0 1
E E S H S H
P P I S I S
I I U C U C
I I I I I I
H.110 bus
Ethernet bus
HW
F F S S F F
C C M M C C
S S U U C C
U U I I U U
FrameA
0 1
Figure 2-2 Backup processing path of signaling over TDM
1) The E1 interface of the EPII 0 provides a TDM PCM interface to access standard
64 kbit/s or 2 Mbit/s SS7 signaling links.
2) The EPII 0 processes MTP1 messages and extracts signaling time slots.
3) Because the FCSU 0 is faulty, the EPII 0 automatically sends signaling time slots
to the EPII 1 through the H.110 bus.
2-2
4) The EPII 1 transfers the signaling time slots to the FCSU 1 through the internal
HW.
5) The FCSU 1 processes both MTP2 and MTP3 messages. The FCSU 1 analyzes
the DPC carried by a message. If the message is destined to the board itself, the
FCSU 1 dispatches, based on the SI, the message to the service layer of the
board itself to process the user layer message. Otherwise, the FCSU 1 transfers
the user layer message, based on the NI, OPC, DPC, and CIC, to a designated
FCCU/FCSU through the Ethernet bus for further processing.
Note:
If the EPII providing E1 trunk circuits is faulty, the system cannot change over the
service through the H.110 bus.
2.2 Processing Path for ISUP/INAP over MTP3/M2UA

2.2.1 Uplink Path
The uplink path in SoftX3000 for Integrated Services Digital Network User Part (ISDN
User Part, or ISUP)/Intelligent Network Application Protocol (INAP) over MTP3/SS7
MTP2-User Adaptation Layer (M2UA) is illustrated in Figure 2-3.
FE FE
FE FE Core LAN Switch Core LAN Switch
B B S H S H
F F I S I S
I I U C U C
I I I I I I
Shared
resource bus
Ethernet bus
I I B B S S F F
F F S S M M C C
M M G G U U C C
I I I I I I U U
Frame A
Figure 2-3 Uplink path for ISUP/INAP over MTP3/M2UA
2-3
Note:
If the destination BSGI and FCCU/FCSU are resident in a different frame, the dispatch
path passes the HSCI and core LAN Switch in the local frame, the HSCI in the
destination frame with the destination FCCU/FCSU, and the destination BSGI and
destination FCCU/FCSU.
1) The BFII provides an external IP interface to receive IP packets, processes

physical-layer messages, and transfers the packets to an IFMI through a fixed
connection.
2) The IFMI processes the MAC messages, and subsequently dispatches them to a
designated BSGI through the Ethernet bus for further processing, based on the IP
protocol type, local IP address, local SCTP port number, peer IP address, and
peer SCTP port number. The correspondence between BSGI board number and
the combination of IP protocol type, local IP address, local SCTP port number,
peer IP address and peer SCTP port number must be configured manually. That is
level-1 message dispatch, also called bearer signaling message dispatch.
3) The BSGI processes IP, SCTP, M2UA and MTP3 messages, and subsequently
transfers them to the ISUP and SCCP dispatch modules of the board itself. The
ISUP dispatch module dispatches the received messages to an FCCU/FCSU
responsible for their CIC through the Ethernet bus according to the NI, OPC, DPC
and CIC in the messages. The SCCP dispatch module dispatches the received
messages to an FCCU/FCSU responsible for their transactions according to the
TCAP/INAP transaction ID.
Caution:
Media Gateway Control Protocol (MGCP), H.248 and SCTP can only be processed by
a BSGI rather than MSGI or IFMI.
4) The FCCU/FCSU processes the ISUP/INAP messages.
2.2.2 Downlink Path
The downlink path in SoftX3000 for ISUP/INAP over MTP3/M2UA is illustrated in Figure
2-4.
2-4
FE FE
IP IP Core LAN Switch Core LAN Switch
B B S H S H
F F I S I S
I I U C U C
I I I I I I
Shared
resource bus
Ethernet bus
I I B B S S F F
F F S S M M C C
M M G G U U C C
I I I I I I U U
Frame A
Figure 2-4 Downlink path for ISUP/INAP over MTP3/M2UA
1) The FCCU/FCSU transmits received messages to a BSGI through the Ethernet

bus according to the BSGI module number of the associated M2UA/MTP3 link.
2) The BSGI processes the M2UA and MTP3 messages, determines an IFMI
according to the source IP address of the IP packets, and subsequently
dispatches associated messages to the determined IFMI through the Ethernet
bus.
3) The IFMI processes the MAC-layer messages, and then transfers the IP
messages to a BFII through a fixed connection.
4) The IP signaling message packets are driven by the BFII, and then distributed out
of SoftX3000 through the network cable connected with the BFII.
2.3 Processing Path for ISUP/INAP over M3UA

2.3.1 Uplink Path
The uplink processing path in SoftX3000 for ISUP/INAP over M3UA is illustrated in
Figure 2-5.
2-5
FE FE
B B S H S H
F F I S I S
I I U C U C
I I I I I I
Shared
resource bus
Ethernet bus
I I B B S S F F
F F S S M M C C
M M G G U U C C
I I I I I I U U
Frame A
Figure 2-5 Uplink path for ISUP/INAP over M3UA

connection.
3) The BSGI processes IP, SCTP, and M3UA messages, and subsequently transfers
them to the ISUP and SCCP dispatch modules of the board itself. The ISUP and
SCCP dispatch modules perform a level-2 dispatch through the Ethernet bus
according to the following principles:
z For ISUP messages, the BSGI dispatches them to an FCCU/FCSU responsible
for their CIC according to the NI, OPC, DPC and CIC of the messages.
z For SCCP messages, the BSGI dispatches them to an FCCU/FCSU responsible
for their transactions according to the TCAP/INAP transaction ID.
4) The FCCU/FCSU processes the ISUP/INAP messages.
2.3.2 Downlink Path
The downlink processing path in SoftX3000 for ISUP/INAP over M3UA is illustrated in
Figure 2-6.
2-6
FE FE
B B S H S H
F F I S I S
I I U C U C
I I I I I I
Shared
resource bus
Ethernet bus
I I B B S S F F
F F S S M M C C
M M G G U U C C
I I I I I I U U
Frame A
Figure 2-6 Downlink path for ISUP/INAP over M3UA

bus according to the BSGI module number of the associated M3UA link.
2) The BSGI processes the M3UA and SCTP messages, determines an IFMI
bus.
2.4 Processing Path for MGCP/H.248 over UDP
Note:
R2 messages are carried in H.248 messages. The processing paths for R2 messages
are the same as those for MGCP/H.248 messages.
2-7
2.4.1 Uplink Path
The uplink processing path in SoftX3000 for MGCP/H.248 over User Datagram
Protocol (UDP) is illustrated in Figure 2-7.
FE FE
B B S H S H
F F I S I S
I I U C U C
I I I I I I
Shared
resource bus
Ethernet bus
I I B B C C S S F F
F F S S D D M M C C
M M G G B B U U C C
I I I I I I I I U U
Frame A
Figure 2-7 uplink path for MGCP/H.248 over UDP
1) The BFII provides an external IP interface to receive IP packets communicated

with media gateways, processes physical-layer messages, and transfers the
packets to an IFMI through a fixed connection.
2) The IFMI processes MAC messages, and subsequently dispatches them to a
BSGI through the Ethernet bus according to BSGI function configuration and
load-sharing principle.
3) The BSGI processes MGCP/H.248 lower-layer protocol messages, and
subsequently dispatches them according to the principles described in Table 2-1.
Table 2-1 MGCP/H.248 level-2 message dispatch paths for BSGI
Message type Path Remark

1) The BSGI sends messages to a CDBI capable of
dispatching MGCP/H.248 messages.
Registration 2) The CDBI queries the correspondence table between
messages from a media gateway domain name and pertaining None
media gateway FCCU/FCSU module number, and subsequently
transfers messages to the FCCU/FCSU module
responsible for managing the gateway or termination.
2-8
Message type Path Remark

The BSGI dispatches messages to a pertaining
FCCU/FCSU according to Request ID. For permanent The range of
Notify messages
event messages with Request ID 0, the BSGI transfers Request ID is
from a media
them to a CDBI which will query the FCCU/FCSU module assigned by the
gateway
number the termination belongs to and then transfer FCCU/FCSU.
messages to that module.
Delete Connection
The BSGI transfers messages to a CDBI. The CDBI
(DLCX) messages
queries the FCCU/FCSU module number the termination None
from a media
belongs to and then transfers messages to that module.
gateway
The range of
Response
Transaction ID
messages from a The BSGI dispatches messages to a pertaining
is assigned by
media gateway to FCCU/FCSU according to Transaction ID.
the
SoftX3000
FCCU/FCSU.
4) The FCCU/FCSU processes the MGCP/H.248 messages.
2.4.2 Downlink Path
The downlink processing path in SoftX3000 for MGCP/H.248 over UDP is illustrated in
Figure 2-8.
FE FE
B B S H S H
F F I S I S
I I U C U C
I I I I I I
Shared
resource bus
Ethernet bus
I I B B S S F F
F F S S M M C C
M M G G U U C C
I I I I I I U U
Frame A
Figure 2-8 Downlink path for MGCP/H.248 over UDP
2-9
1) For the first messages of a call, the FCCU/FCSU chooses a BSGI based on the
load sharing principle. For the subsequent messages of the same call, the
FCCU/FCSU dispatches them to that BSGI.
2) The BSGI processes MGCP/H.248 codec and UDP messages. According to the
source IP address carried in the UDP packet, the BSGI compares the source IP
address with the IP addresses of IFMIs and chooses an IFMI of the IP address
system for dispatch purpose.
2.5 Processing Path for H.323 over IP

The H.323 includes H.323 RAS (Registration, Admission and Status) and H.323 CALL
(Q.931 and H.245). H.323 RAS is carried over UDP and H.323 CALL is carried over
TCP.
2.5.1 Uplink Path
The uplink processing path in SoftX3000 for H.323 is illustrated in Figure 2-9.
FE FE
B B S H S H
F F I S I S
I I U C U C
I I I I I I
Shared
resource bus
Ethernet bus
I I M M C C S S F F
F F S S D D M M C C
M M G G B B U U C C
I I I I I I I I U U
Frame A
Figure 2-9 Uplink path in SoftX3000 for H.323

connection.
2-10
2) The IFMI processes the MAC message to determine whether the message type is
H.323 RAS or H.323 CALL. The IFMI dispatches the H.323 RAS and H.323 CALL
messages to MSGI with different dispatch principles.
z Level-1 dispatch of H.323 RAS
The IFMI dispatches the H.323 RAS message to a specified MSGI according to data
configuration.
Note:
z Multiple MSGIs can be configured manually to process H.323 RAS. However at a
single time point, only one MSGI is processing RAS requests and other MSGIs work
in the standby mode.
z In case of a small capacity of configurations, you can load MSGI program and data
to an IFMI so that the IFMI can function as an MSGI.
z Level-1 dispatch of H.323 CALL

The IFMI adopts different dispatch strategies according to different destination ports of
the TCP message. These ports can be well-known port (1720) or local port. If the
destination port is a H.323 CALL local port, the IFMI will dispatch the message
according to the relationship between H.323 CALL local port number and MSGI module
number. If the destination port is a well-known port, the IFMI will dispatch the message
to the MSGI for processing in load sharing mode.
When SoftX3000 serves as a gatekeeper (GK), the destination port of the first H.323
CALL Signaling message initiated by the H.323 terminal is a well-known port. The IFMI
dispatches the message to an MSGI in load sharing mode. The IFMI returns an H.323
CALL Signaling message to the H.323 terminal with H.323 Call Signaling local port of
the MSGI. When all subsequent H.323 CALL Signaling messages of the H.323 terminal
arrive at the IFMI, the IFMI dispatches them to the MSGI according to the manually
configured relationship between H.323 Call Signaling local port number and the MSGI
module number.
When SoftX3000 serves as an H.323 gateway (GW), the destination port of the first
H.323 CALL Signaling message sent from the IFMI is a destination port (1720). The
destination port for the H.323 CALL Signaling message that the peer end server returns
is also a destination port (1720). The IFMI dispatches the message to an MSGI in load
sharing mode. The H.323 CALL Signaling message that IFMI returns to the peer end
server will include the H.323 Call Signaling local port of the MSGI. When all subsequent
H.323 CALL Signaling messages of the same call from the peer end H.323 server
arrive at the IFMI, the IFMI dispatches them to the MSGI according to the manually
configured relationship between H.323 Call Signaling local port number and the MSGI
module number.
2-11
Note:
z Each MSGI is configured with one H.323 CALL local port. The whole SoftX3000 is
configured with one H.323 CALL well-known port (1720).
z In the H.323 protocol, a normal call process includes a Q.931 TCP connection and
an H.245 TCP connection. The Q.931 TCP connection and H.245 TCP connection
vary with different calls. All Q.931 messages of the same call are transferred
through the same TCP connection. Similarly, all H.245 messages of the same call
are transferred through the same TCP connection.
3) The MSGI processes H.323 RAS and H.323 Call Signaling protocols, and
subsequently dispatches them according to different principles. Level-2 dispatch
principles of H.323 RAS messages are shown in Table 2-2. Level-2 dispatch
principles of H.323 CALL Signaling messages are shown in Table 2-3.
Table 2-2 Level-2 dispatch principles of H.323 RAS messages
Message type Path

1) The MSGI queries the database on the local board
for the correspondence between EndPointID and
FCCU/FCSU.
2) If the query is completed successfully, the MSGI

dispatches the level-2 messages to the found
FCCU/FCSU.
Admission Request (ARQ), a
If the query fails, the MSGI turns to a CDBI for the
type of call related request
correspondence between Call ID and FCCU/FCSU.
On receipt of the found FCCU/FCSU module number
returned by the CDBI, the MSGI dispatches that
message to that FCCU/FCSU for processing.
Meanwhile, the MSGI records in its own database
the correspondence between that Call ID and that
pertaining FCCU/FCSU.
Other call related requests,

such as Disengage Request The MSGI dispatches messages to an FCCU/FCSU
(DRQ), Information Request which is determined according to manual data
(IRQ), and Bandwidth configurations.
Request (BRQ)
The MSGI dispatches messages in the same way as
Non-call related requests,
dispatching ARQs. First the MSGI queries the
such as Registration
database of the local board to obtain a desired
Request (RRQ) and
FCCU/FCSU module number. If the query fails, the
Unregistration Request
MSGI turns to a CDBI for the FCCU/FCSU module
(URQ)
number.
2-12
Table 2-3 Level-2 dispatch principles of H.323 CALL messages
Message type Path

1) For the first message of a call, the MSGI, which is
processing H.323 RAS using the Call ID as the key field,
query the FCCU/FCSU module associated with that call.
2) On receipt of the query result, the MSGI dispatches that
H.323 CALL Signaling message to the found FCCU/FCSU.
If the query fails, the MSGI turns to a CDBI for the
correspondence between Call ID and FCCU/FCSU. On
H.323 user call receipt of the found FCCU/FCSU module number returned by
message the CDBI, the MSGI dispatches that level-2 message to that
FCCU/FCSU for processing. Meanwhile, the MSGI records in
its own database the correspondence between that Call ID
and that pertaining FCCU/FCSU.
3) For subsequent messages of the same call, the MSGI
dispatches them directly to the corresponding FCCU/FCSU
according to the correspondence between Call ID and
FCCU/FCSU in its database.
1) For the first message of a call, the MSGI dispatches it to

any available FCCU/FCSU according to the load sharing
principle, and meanwhile records in its own database the
H.323 trunk call correspondence between Call ID and FCCU/FCSU.
message 2) For subsequent messages of the same call, the MSGI
dispatches them directly to the corresponding FCCU/FCSU
according to the correspondence between Call ID and
FCCU/FCSU in its database.
4) The FCCU/FCSU processes H.323 services.
2.5.2 Downlink Path
The downlink processing path in SoftX3000 for H.323 is illustrated in Figure 2-10.
2-13
FE FE
B B S H S H
F F I S I S
I I U C U C
I I I I I I
Shared
resource bus
Ethernet bus
I I M M S S F F
F F S S M M C C
M M G G U U C C
I I I I I I U U
Frame A
Figure 2-10 Downlink path in SoftX3000 for H.323
The downlink path for H.323 signaling is described in Table 2-4.
Table 2-4 Downlink path for H.323 messages
Message type Path

1) For the first message of a call, the FCCU/FCSU dispatches it
to an MSGI capable of processing H.323 RAS according to the
loading sharing principle. Meanwhile, the FCCU/FCSU records
in its database the module number of that MSGI. For the
subsequent messages of the same call, the FCCU/FCSU
dispatches them directly to the corresponding MSGI according
to the recorded MSGI module number.
2) The MSGI processes H.323 RAS and UDP messages.

H.323 RAS
3) The MSGI dispatches messages to an appropriate IFMI
according to the local IP address carried in the UDP packet to
be delivered.
4) The IFMI processes the MAC-layer messages, and then

transfers the IP messages to a BFII through a fixed connection.
5) The IP signaling message packets are driven by the BFII, and
then distributed out of SoftX3000 through the network cable
connected with the BFII.
2-14
Message type Path

1) For the first message of a call, the FCCU/FCSU dispatches it
to an MSGI capable of processing H.323 CALL according to the
loading sharing principle. Meanwhile, the FCCU/FCSU records
in its database the module number of that MSGI. For the
subsequent messages of the same call, the FCCU/FCSU
dispatches them directly to the corresponding MSGI according
to the recorded MSGI module number.
2) The MSGI processes H.323 CALL and TCP messages.
H.323 CALL
3) The MSGI dispatches messages to an appropriate IFMI
according to the local IP address carried in the TCP packet to be
delivered.
4) The IFMI processes the MAC-layer messages, and then
transfers the IP messages to a BFII through a fixed connection.
5) The IP signaling message packets are driven by the BFII, and
then distributed out of the SoftX3000 through the network cable
connected with the BFII.
2.6 Processing Path for SIP over UDP

2.6.1 Uplink Path
The uplink processing path in SoftX3000 for Session Initiation Protocol (SIP) over UDP
is illustrated in Figure 2-11.
FE FE
B B S H S H
F F I S I S
I I U C U C
I I I I I I
Shared
resource bus
Ethernet bus
I I M M C C S S F F
F F S S D D M M C C
M M G G B B U U C C
I I I I I I I I U U
Frame A
Figure 2-11 Uplink path for SIP over UDP
2-15

connection.
2) The IFMI processes MAC messages, and subsequently judges the destination
port of the UDP message. If the destination port is the SIP local port, the IFMI
performs the level-1 message dispatch according to the correspondence between
SIP local port and MSGI module number. If the destination port is an SIP service
port, the IFMI dispatches messages to any MSGI capable of processing SIP
according to the load sharing principle.
Note:
z Each MSGI is configured with one SIP local port. The whole SoftX3000 is
configured with one SIP service port (5060). On receipt of the first SIP message
carrying the service port number, the IFMI dispatches it to an MSGI according to the
load sharing principle. The reply of that message carries the SIP local port number
of the dispatched MSGI and is distributed out of SoftX3000. For the subsequent
messages of the same call, the IFMI dispatches them to the MSGI according to the
correspondence between the SIP local port and the MSGI.
z In case of a small capacity of configurations, you can load MSGI program and data
to an IFMI so that the IFMI can function as an MSGI.
3) Depending on different message types, the MSGI performs the level-2 dispatch by
complying with different principles as shown in Table 2-5.
Table 2-5 Level-2 dispatch principles of SIP messages
Message
Path
type
1) The MSGI queries the database on the local board for the
correspondence between SIP User ID and FCCU/FCSU.
2) If the query is completed successfully, the MSGI dispatches
messages to the found FCCU/FCSU.
Register If the query fails, the MSGI turns to a CDBI for the correspondence
between SIP User ID (user name or E.164 number) and
FCCU/FCSU. On receipt of the found FCCU/FCSU module number
returned by the CDBI, the MSGI dispatches the level-2 messages to
that FCCU/FCSU for processing. Meanwhile, the MSGI records in its
own database the correspondence between that SIP User ID (user
name or E.164 number) and that pertaining FCCU/FCSU.
1) For the first message of a call, the MSGI queries the database on
SIP user call
the local board for the correspondence between SIP User ID and
message
FCCU/FCSU.
2-16
Message
Path
type
2) If the query is completed successfully, the MSGI dispatches the
SIP level-2 message to the corresponding FCCU/FCSU according to
the found FCCU/FCSU module number.
If the query fails, the MSGI turns to a CDBI for the desired
FCCU/FCSU module number corresponding to SIP User ID. On
receipt of the found FCCU/FCSU module number, the MSGI
dispatches the SIP level-2 message to the corresponding
FCCU/FCSU, and meanwhile records in its database the
correspondence between SIP User ID and FCCU/FCSU.
3) For subsequent messages of the same call, the MSGI dispatches
SIP user call
them directly to the corresponding FCCU/FCSU according to the
message
correspondence between User ID and FCCU/FCSU in its database.
1) For the first message of a call, the MSGI dispatches it to any

available FCCU/FCSU according to the load sharing principle, and
meanwhile records in its own database the correspondence
SIP trunk call between Call ID and FCCU/FCSU.
message
2) For subsequent messages of the same call, the MSGI dispatches
them directly to the corresponding FCCU/FCSU according to the
correspondence between Call ID and FCCU/FCSU in its database.
4) The FCCU/FCSU processes the SIP service messages.
2.6.2 Downlink Path
The downlink processing path in SoftX3000 for SIP over UDP is illustrated in Figure
2-12.
2-17
FE FE
B B S H S H
F F I S I S
I I U C U C
I I I I I I
Shared
resource bus
Ethernet bus
I I M M S S F F
F F S S M M C C
M M G G U U C C
I I I I I I U U
Frame A
Figure 2-12 Downlink path for SIP over UDP
1) For the first message of a call, the FCCU/FCSU dispatches it to an MSGI capable
of processing SIP according to the loading sharing principle. Meanwhile, the
FCCU/FCSU records in its database the module number of that MSGI. For the
subsequent messages of the same call, the FCCU/FCSU dispatches them directly
to the corresponding MSGI according to the recorded MSGI module number.
2) The MSGI processes SIP and UDP messages
3) The MSGI dispatches messages to an appropriate IFMI according to the local IP
address carried in the UDP packet to be delivered.
of the SoftX3000 through the network cable connected with the BFII.
2.7 Processing Path for DSS1 over IUA

2.7.1 Uplink Path
The uplink processing path for Digital Subscriber Signaling No. 1 (DSS1) over ISDN
User Adaptation Layer (IUA) is illustrated in Figure 2-13.
2-18
FE FE
B B S H S H
F F I S I S
I I U C U C
I I I I I I
Shared
resource bus
Ethernet bus
I I B B S S F F
F F S S M M C C
M M G G U U C C
I I I I I I U U
Frame A
Figure 2-13 Uplink path for DSS1 over IUA

connection.
protocol type, source IP address (IP address of the opposite device), source port
number (port number of the opposite device), destination IP address, destination
port number (SoftX3000), and local SCTP port number. The correspondence
between BSGI board number and the combination of IP protocol type, source IP
address, source port number, destination IP address, destination port number,
and local SCTP port number must be configured manually. That is level-1
message dispatch, also called bearer signaling message dispatch.
3) The BSGI processes the IP, SCTP and IUA messages, and subsequently
dispatches messages to an FCCU/FCSU according to the correspondence
between D link and FCCU/FCSU module number. The correspondence between
D link and FCCU/FCSU module number must be configured manually.
4) The FCCU/FCSU processes the third-layer messages of DSS1 signaling.
2.7.2 Downlink Path
The downlink processing path in SoftX3000 for DSS1 over IUA is illustrated in Figure
2-14.
2-19
FE FE
B B S H S H
F F I S I S
I I U C U C
I I I I I I
Shared
resource bus
Ethernet bus
I I B B S S F F
F F S S M M C C
M M G G U U C C
I I I I I I U U
Frame A
Figure 2-14 Downlink path for DSS1 over IUA

bus according to the BSGI module number of the associated IUA link.
2) The BSGI processes the IUA and SCTP messages, determines an IFMI according
to the source IP address of the IP packets, and subsequently dispatches
associated messages to the determined IFMI through the Ethernet bus.
of the SoftX3000 through the network cable connected with the BFII.
2.8 Processing Path for V5.2 over V5UA

2.8.1 Uplink Path
The uplink processing path in SoftX3000 for V5.2 over V5 User Adaptation Layer
(V5UA) is illustrated in Figure 2-15.
2-20
FE FE
B B S H S H
F F I S I S
I I U C U C
I I I I I I
Shared
resource bus
Ethernet bus
I I B B S S F F
F F S S M M C C
M M G G U U C C
I I I I I I U U
Frame A
Figure 2-15 Uplink path for V5.2 over V5UA

connection.
3) The BSGI processes the IP, SCTP and V5UA messages, and subsequently
dispatches messages to an FCCU/FCSU according to the correspondence
between V5 link and FCCU/FCSU module number. The correspondence between
V5 link and FCCU/FCSU module number must be configured manually.
4) The FCCU/FCSU processes the V5 messages.
2.8.2 Downlink Path
The downlink processing path in SoftX3000 for V5.2 over V5UA is illustrated in Figure
2-16.
2-21
FE FE
B B S H S H
F F I S I S
I I U C U C
I I I I I I
Shared
resource bus
Ethernet bus
I I B B S S F F
F F S S M M C C
M M G G U U C C
I I I I I I U U
Frame A
Figure 2-16 Downlink path for V5.2 over V5UA

bus according to the BSGI module number of the associated V5UA link.
2) The BSGI processes the V5UA and SCTP messages, determines an IFMI
bus.
2-22
U-SYS SoftX3000 SoftSwitch System Chapter 3 Operation and Maintenance Principle
Chapter 3 Operation and Maintenance Principle
3.1 Hardware Architecture of Terminal System

The hardware architecture of the SoftX3000 terminal system is illustrated in Figure 3-1.
S S
M M
U U
I I
Basic frame 0
S H S H
I S I S
U C U C
I I I I
LAN Switch0 LAN Switch1
To billing
To billing WAN
WAN center
center
Emergency Active
Standby iGWB BAM
workstation iGWB
Alarm box
To NMS
HUB
WAN
WS WS
Figure 3-1 Hardware architecture of terminal system
3.1.1 BAM
The BAM functions as a server for the operation and maintenance (OAM) system of the
whole equipment, bridging the SoftX3000 and workstations. The BAM is used to
transfer maintenance commands from both local and remote workstations to
SoftX3000 and direct responses from SoftX3000 to the proper operation and
maintenance workstation, as well as implementing storage and transfer of data such as
alarm information and traffic measurement.
Note:
SoftX3000 is sometimes called “foreground” or “host”. BAM is sometimes called
background.
3-1
3.1.2 iGWB
I. iGWB Server
The iGWB server located between SoftX3000 and a billing center is responsible for
receiving, pre-processing, and buffering bills and provides billing interfaces. The bill
processing capability of the iGWB server is 1700 detailed bills per second.
II. Hard Disk Array
If you choose an IBM server as the iGWB, it is required to use IBM.EXP300 hard disk
array. The standard configuration of the hard disk array is ten 1-inch hot swappable
hard disks, which can be expanded to a maximum of 14 hard disks.
Note:
In case that the communication fails between the iGWB and the billing center, the
original bills will be stored on the hard disk array for a maximum of seven days.
3.1.3 Emergency Workstation
The emergency workstation can automatically back up the data on the BAM. By default,
it initiates a synchronization request every 4 hours. When the BAM is faulty, the
emergency workstation works as a BAM with the data backed up from BAM database.
When the faulty BAM is recovered, the emergency workstation will stop working as a
BAM. The system returns to the normal mode. Therefore, the emergency workstation is
a backup media of BAM data.
As shown in Figure 3-1, the emergency workstation and LAN Switches are
interconnected through dotted lines, indicating the paths are not available when BAM is
normal. In case that the BAM is faulty, connect the emergency workstation and LAN
switches so that the emergency workstation can replace the BAM to function
temporarily.
3.1.4 Workstation
SoftX3000 terminals include maintenance terminals and operation terminals. The

terminals achieve data configuration, device state query, and maintenance functions.
3.2 Software Architecture of Terminal System

The software of the SoftX3000 terminal system includes local maintenance system
(BAM, workstation and communication gateway), network management system (NMS),
and billing gateway system (iGWB). The local maintenance system and the billing
3-2
gateway are mandatory in the SoftX3000 terminal system; the NMS is optional. The
logic structure of the SoftX3000 terminal system is illustrated in Figure 3-2.
NMS Upper NMS
Local maintenance
system
Host software
Terminal
BAM
OAM
software
software
BAM WS
Communication
gateway
SoftX3000
iGWB Billing
software center
iGWB
Terminal System
Figure 3-2 Logic structure of terminal system
Note:
z For the principle of the billing gateway system, refer to Chapter 4 “Charging System”
of this manual and U-SYS iGateway Bill User Manual.
z For working principles of the NMS software, refer to HUAWEI iManager N2000
Fixed Network Integrated Management System NGN NM Solution User Manual.
z The BAM and the iGWB communicate with SoftX3000 respectively. The former
operates and maintains the system; the latter manages bills.
z The BAM and the NMS interact through the standard Man-Machine Language
(MML) and Simple Network Management Protocol (SNMP). In this way, NMS
maintains and manages the SoftX3000 in a centralized mode. The NMS provides
an access interface to its upper NMS.
z Usually, the BAM and workstations communicate through Ethernet interface using
TCP/IP. They can also communicate through serial port using the gateway tool.
3-3
3.2.1 BAM Software
The BAM software running on the BAM enables operator to manage and maintain the
system, including managing and maintaining the SoftX3000 running data, traffic
measurement data and alarm information. The SoftX3000 provides a complete set of
practical methods and tools to guarantee the normal running of the system, minimize
the operation costs, and improve the quality of service.
I. Networking of BAM
The BAM is the core of the local operation and maintenance system. Being the TCP/IP
server, the BAM responds to connection requests from clients (or workstations),
creates connections, analyzes commands from clients, and carries out appropriate
processing. Meanwhile, the BAM responds to connection requests from the equipment,
creates connections, achieves the communication between the BAM and the
equipment, and receives and processes data loading requests and alarms from the
equipment.
The BAM provides two network interfaces to core LAN Switches, thereby being
connected to the HSCIs in the basic frames. The two network interfaces provided by
the BAM are respectively in the same network segment with the active/standby SMUIs
(two closed LANs connected to the equipment). The connection to a client belongs to a
different network segment (an open operation and maintenance LAN). The three
network segments are not seeable with each other. In this way, the network security is
ensured to a certain extent and the dependence on the system security is reduced.
Figure 3-3 shows the network configuration of the BAM.
3-4
S S
M M
U U
I I
Basic frame 0
S H S H
I S I S
U C U C
I I I I
LAN Switch 0 LAN Switch 1
NIC1 NIC 2 NIC1 NIC2
NIC3 NIC3
Emergency
BAM
workstation
LAN
WS 0 WS 1
BAM: Backend Administration Module WS: Workstation

Network interface card Local area network
Figure 3-3 Network configuration of BAM
Note:
The IP address of the NIC1 is set to 172.20.200.0. The IP address of the NIC2 is
172.30.200.0.
II. Composition of BAM Software
Figure 3-4 shows the components of the BAM software.
3-5
BAM
Service
Monitor
Shake hand
Security
SNMP Monitor Manager
Interface
SNMP
Dataman
Agent
Maintain
MML GUI MML Exchange Device
Server
Warn
WS
LogMan
Statstics
SQL Bill
Server
BAM
Figure 3-4 BAM software composition
The BAM software is composed of the following parts:

z SQL Server stores the service data and provides database support for the service
servers.
z Logman logs the operation process and provides log query functions and
malicious operation tracing functions for clients.
z MML Server communicates with workstations, manages operator authorities,
interprets commands input from workstations, and dispatches workstation
commands.
z SNMP Agent provides a standard SNMP interface to the NMS.
z Exchange is a communication module between the BAM and the host. It provides
program and data loading functions, and dispatches messages returned from the
host.
z Security Manager is a function management module for the software of the whole
equipment. It manages other service processing modules and monitors their
running state.
z BAM Service monitors the Security Manager. It can also restart the BAM.
z Bill: A bill process responsible for collecting and sorting IP Centrex bills.
z Statistics is a traffic measurement process. It processes traffic measurement
data—creating traffic measurement tasks and querying measurement results.
z Warn is an alarm process. It processes equipment alarms and BAM alarms. It also
provides alarm reports and alarm query functions for workstations, and drives the
alarm box.
3-6
z Maintain is a maintenance process. It processes equipment maintenance

commands—patching programs and tracing signaling.
z Dataman is a data configuration process. It processes configured and backed-up
data, for instance, processing call prefix and equipment data.
III. Features of BAM
1) High reliability
BAM uses SQL Server as the database system on a carrier-class server. It employs
redundant arrays of inexpensive disks (RAID 1) technique. In this way, it applies the
multi-layer self-monitoring measures to back up and restore data conveniently and
reliably.
2) Client/Server structure
The BAM software is integrated with communication server and database server. All
maintenance tasks are implemented in the client/server model. You can configure data
locally and remotely at the same time. Maintenance can be achieved conveniently and
quickly.
3) Remote maintenance
The SoftX3000 provides remote maintenance functions and supports flexible
networking models. The SoftX3000 can be connected to a remote maintenance system
through a digital data network (DDN), E1 time slot, frame relay, X.25 network, or dial-up
to public switched telephone network (PSTN). The following details a commonly used
method, iWeb remote maintenance scheme.
As shown in Figure 3-5, Huawei iWeb remote maintenance system is based on the
Internet. It enhances remote monitoring and encrypted data transmission, and thereby
guarantees the security of the running of the equipment.
3-7
Client Agent LAN
Remote WS Proxy Host
LAN Switch Internet
LAN
Device
Firewall
BAM Server Agent
Client Agent: Receiving data from remote Server Agent: Receiving data from the
maintenance workstations and transferring the Client Agent and transferring the data to
data to the Server Agent the BAM
Proxy HOST: Proxy Server
Figure 3-5 Networking model of iWeb remote maintenance solution
iWeb remote maintenance system has the following features:

z The original system does not need to be changed. You can remotely maintain the
SoftX3000 through the iWeb remote maintenance system.
z Data transfer: A bi-directional data channel is established between the Client
Agent and the Server Agent and between the remote maintenance workstation
and the BAM, to transfer ordinary requests and active reports between the remote
maintenance workstation and the BAM.
z The SoftX3000 supports to traverse proxy and firewall. SoftX3000 supports user
authentication and Windows NT challenge/response (NTLM) authentication at the
proxy server. Through the tunnel technique based on Hyper Text Transport
Protocol (HTTP), an HTTP port is made public to outside by the firewall, which is
enough to achieve the traversing through firewall.
z Before data transmission, iWeb encrypts data to ensure the security and
compresses data to save the bandwidth.
z The SoftX3000 supports access policy control, such as authorization based on the
IP address of a remote maintenance workstation, authorization based on a time
segment, and real-time authorization for an unauthorized remote maintenance
workstation.
z The SoftX3000 helps the remote maintenance personnel communicate with local
maintenance personnel in the text format, thus saving communication expenditure
during the maintenance process.
3-8
z You can monitor maintenance operations and requests from remote clients in real
time. Once SoftX3000 is suspicious of a client, the connection to that client is cut.
z The SoftX3000 logs all maintenance operations from clients for future reference.
The SoftX3000 can also generate a report recording the maintenance operations
from clients.
4) MML command lines and Graphical User Interface (GUI) interfaces
SoftX3000 provides MML command line interfaces which are compliant with
International Telecommunication Union – Telecommunication Standardization Sector
(ITU-T) recommendations. SoftX3000 also supports friendly GUIs.
z MML
You can conduct data configuration, performance management, and maintenance on
SoftX3000 in the MML manner.
z GUI
User can manage alarm information, trace signaling and interfaces, and observe
device state through GUI.
5) Openness
SoftX3000 employs the standard TCP/IP protocols and distributed database
technology, complying with the Open Systems Interconnection (OSI) reference model.
SoftX3000 can be connected to a variety of large databases with transparent access,
thereby facilitating the provision of various value added services and intelligent
services. When necessary, user can install peripheral devices such as hard disk array,
disk drive, printer, and Magneto-Optical (MO) drive. Moreover, it is easy to add more
operation and maintenance terminals.
6) Optimized security measures
z The log function provided by the BAM enables to correctly record all operations
performed by operators.
z SoftX3000 supports to isolate a private network from the public network, thereby
achieving screening from outside.
z The relationship among configured data is not seeable to user, which ensures the
consistency of the data.
z SoftX3000 supports to back up data in a scheduled way, thereby improving the
system ability of resisting emergencies.
3.2.2 Operation and Maintenance Software
The operation and maintenance (OAM) software of SoftX3000 can be installed in both
local and remote workstations. Through communication with the BAM, local and remote
operation and maintenance functions can be achieved. Workstations and the BAM can
communicate through a local area network (LAN), Wide Area Network (WAN), or serial
port.
3-9
In the client/server mechanism, a SoftX3000 operation and maintenance terminal

functions as a client and the BAM as a server. The client provides operation and
maintenance interfaces for user. The OAM software provides MML-based graphical
interfaces. The OAM software is composed of the service maintenance system, the
alarm console, and the traffic measurement report system.
I. Service Maintenance System
The MML-based graphical terminal software is composed of the following functional

modules:
1) MML navigation tree module
On the MML navigation tree, operator can find the basic operation command sets of
SoftX3000. Command sets with the same properties are classified on the same branch
of the navigation tree. Expand the MML command tree, and operator can find a number
of MML command nodes. Double clicking an MML command node opens the
corresponding command input window and assistant window. What operator needs to
do is to type a command and set values for parameters. The MML module will
automatically generate a command report to dispatch. Through the MML module,
operator can perform a variety of operations on SoftX3000, such as data configuration,
performance management, and subscriber management.
2) Maintenance navigation tree module
The maintenance navigation tree module displays maintenance command sets in a
tree form. Maintenance operations may be associated with trace and device panel. The
maintenance navigation tree module provides the following functions:
z Maintenance management
Maintenance management provides multiple maintenance control methods such as
query, display, switchover, reset, isolation, block and activation. By using these
maintenance control methods, efficient management and maintenance can be
performed on the hardware components, system resources, signaling links, clock links
and physical ports of the SoftSwitch system, as well as the gateways and terminals
under its control.
z Trace management
Trace management provides functions such as connection tracing, signaling tracing,
interface tracing and message interpretation. By using these functions, a real-time and
dynamic trace can be conducted on the connection process, state transition, resource
occupancy, telephone number information transfer and control information streams
relating to the terminal users, trunk circuits, signaling links and interface protocols. The
tracing information can be preserved for future reference. In this way, powerful fault
analysis and location capabilities can be provided for users.
z Signaling analysis
3-10
Signaling analysis provides a built-in signaling analysis software which is developed

independently by Huawei. The software works along with the trace management
functions to analyze the signaling interaction processes in an online or offline way.
Signaling analysis provides strong maintenance approaches to quickly locate the
cause of a fault and also to optimize the configuration of signaling links.
II. Alarm Console
The alarm console correctly reflects the alarms recorded in the BAM in real time.
Through the alarm console, operator can query and view all alarms as well as
managing the alarms.
Alarm information includes the alarm name, generation (and restoration) time, alarm
level, locating information, and recovery recommendations.
III. Traffic Measurement Report System
Traffic measurement (traffic statistics) performs measurements and statistics on the

services and objects of a variety of call types. By analyzing the statistic data, the
running conditions of the SoftSwitch, the gateways, the whole network and the
terminals can be known, which provides the basic data for the planning, design,
operation, management and maintenance of the telecommunication network.
3.2.3 Communication Gateway Software
The communication gateway provides a new way for the communication between the
BAM and workstations, that is, serial port communication. To achieve such
communication, interconnect the BAM and respective workstations through serial port
cable. The communication gateway includes a communication gateway at the BAM
and a communication gateway at the workstation. They convert messages between
TCP/IP packets and RS232 serial port signals.
On the BAM and the emergency workstation, the communication gateway software is
installed both on the BAM and the workstation. In the communication gateway software
at the BAM, you can access an alarm box by setting the “client application” to “New
AlarmBox Class”. Generally, it is recommended to access the alarm box at the
emergency workstation rather than the BAM, as shown in Figure 3-6.
3-11
Figure 3-6 The settings of BAM Communication Gateway when connecting the alarm
box at the BAM or the emergency workstation
Only the communication gateway at the workstation is installed with the workstation
communication gateway software. Currently, the OAM system uses Ethernet
networking model only. Therefore, the BAM and the workstation communicate in a
TCP/IP network. Because the serial port is rarely used, the workstation communication
gateway software is rarely used.
3.3 Security Management

The SoftX3000 maintenance management subsystem can be operated by multiple
users. To ensure the security and convenience of the system, different authorities are
assigned to different operators and workstations.
The availability of an MML command depends on both operator authority and
workstation authority. When both conditions are satisfied, you can execute the
command.
Features of authority management model: An operator, even the system administrator,
is unable to perform all operations on any of the workstations. Generally, the
workstations are distributed in different places. The significant commands are available
to different workstations and accounts. This mechanism guarantees both the security
and the flexibility of the system.
3-12
3.3.1 Command Group
The command group is the basic unit in authority management. A command group
defines the authorities assigned to an operator or workstation. A command can belong
to one or more command groups. When an operator or workstation has the authorities
of a command group, all commands in the command group are available to the
operator or workstation.
66 command groups are defined in the SoftX3000 maintenance management
subsystem, including G_0 to G_63, G_SYS, and G_GUEST. G_SYS is designed for
super operator, and G_GUEST for operator GUEST. G_0 to G_9 are preset command
groups. They divide most commands in the system according to their functions. Each
command group comprises multiple commands. The operator assigned with a
particular command group is entitled to execute all the commands in the group.
However, the commands related to authority and logging on cannot be allocated to any
command group from G_0 to G_63. Only the system administrator has the authority to
execute those commands. An operator with G_SYS command group authorities is the
system administrator. A workstation with G_SYS command group authorities is called
“super workstation”. In the same system, there can be several super workstations but
only one system administrator. The default user name of the system administrator is set
when the BAM is installed. You cannot change its user name. Only the system
administrator is able to set passwords for other operators. You can define a super
workstation when installing the client software. Alternatively, you can do so with the
command Add WS on the workstation using the system administrator account. The
system administrator can control the whole system on any super workstation. The
operations related to authority management are available only to the system
administrator. Such operations include modifying operator or workstation authority,
modifying commands in a command group, and modifying operator’s login time.
G_GUEST is a command group with the lowest authority. An operator or workstation of
G_GUEST can only execute five pre-defined commands related to the operator or
workstation itself.
3.3.2 Workstation Management
Workstation refers to a computer on which operator sends command requests. If a

workstation is not registered, it can only be used at the G_GUEST level, and only the
commands of the G_GUEST are available. By default, the BAM is set to a super
workstation.
Workstation management includes adding and deleting workstation, setting and
querying workstation information, and setting alarm output switch of workstation. The
workstation management operations are available to the system administrator only.
3-13
3.3.3 Account Management
The SoftX3000 maintenance management subsystem identifies each operator by user

name uniquely. When you have deleted an operator account, you have also invalidated
its authority settings. When you create a new account with the same user name, it will
not inherit the authority settings of the original one. In this way, the system is prevented
from login of the invalid accounts.
In addition, operator password has been encrypted before it is stored in the database.
The security of the cipher text is guaranteed by the safety mechanism of the database
and the encryption algorithm of the password.
3.3.4 Specifying Login Time
The SoftX3000 maintenance management subsystem supports to restrict operator to

log on to the system during a specified time segment. Operator can execute the
commands in the authorized command group only if the operator logs on to the system
during the specified time segment.
3.3.5 Locking the Client
If you do not perform any operation for a specified period of time, the OAM system will
be locked automatically. To unlock the system, input the correct password. The
automatic locking of client is designed to prevent unauthorized access to the system. It
further guarantees the validity and security of the system.
You can click [System/Auto Lock Setting…] to set the automatic locking time.
3.4 Data Storage

Data of SoftX3000 falls into three types, namely BAM data, SoftX3000 data and
supplementary service data.
3.4.1 Storage of BAM Data
All BAM data is stored in the SQL Server of the BAM. The data management program
on the BAM helps you define operator authorities hierarchically.
You can backup BAM data automatically at a scheduled time or manually. It is
recommended to backup BAM data before modifying important system data.
3.4.2 Storage of Host Data
The storage of host data includes two modes: host data backed up in the Flash Memory
and host data not backed up in the Flash memory.
3-14
I. Host Data Backed Up in the Flash Memory of the Board
When a board successfully loads the data to its Basic Input/Output System (BIOS), the
host automatically backs up the data in the flash memory of the board. Once the system
is powered on and started, the host can load the data from the BAM or from the flash
memory of the board. The selection of loading path is determined by a soft setting
switch on the BAM.
If data setting operations are carried out on the BAM, the backup program module of
the active board automatically backs up the modified static data both to the flash
memory of the active board and the database in the memory of the standby board. In
addition, the backup program module of the standby board synchronizes the modified
database in the memory of the standby board to the flash memory of the standby board
at a scheduled time point.
Data of the SMUI and the FCCU/FCSU is backed up in the flash memory of the
corresponding board.
II. Host Data Not Backed Up in Flash Memory of Board
Certain boards must accommodate a large volume of data. For example, the CDBI
accommodates data about all subscribers, trunks, H.323, SIP, MGCP and H.248. Such
a volume of data is much larger than the capacity of the flash memory of the board.
Therefore, the system configuration data of such boards is not backed up in the flash
memory of the local board. Whenever such a board is started, data must be loaded
from the BAM. If data setting operations are carried out on the BAM, the setting
operations affect both the active and standby boards simultaneously. The modification
of the data on the active board will not lead to a backup on the standby board.
3.4.3 Storage of Supplementary Services
Data of supplementary services (such as wake-up service and hotline service) of PSTN
subscribers is dynamically stored in the database of SoftX3000. To protect the
supplementary service data, the following measures are taken in the system.
z Consistency check for supplementary service data is carried out periodically.
Inconsistent data will be cleared as long as it is found.
z Whenever a subscriber modifies his supplementary services, a piece of dynamic
data is generated on SoftX3000, and meanwhile the data is transferred to the BAM
for backup. This is a kind of incremental backup.
z Periodically the BAM sends a request to SoftX3000 to back up supplementary
service data for restoration purposes in case of a SoftX3000 database failure. This
is a kind of complete backup. In addition, whenever a board starts, it actively
sends a request to the BAM to restore the dynamic data of supplementary
services of PSTN subscribers.
z Whenever the standby board is switched to be active, it actively sends a request to
the BAM to restore the supplementary service data.
3-15
3.5 Data Loading and Data Operation

3.5.1 Data Loading
The host of the SoftX3000 is composed of multiple OSTA frames. These frames
communicate through internal Ethernet. Each frame has active/standby network cables
connecting to LAN Switch 0 and LAN Switch 1. Therefore, the process of loading
software and data to the host through the BAM, is actually the process of loading
software and data to the boards of the frames.
By taking the loading process of a frame as an example, this section describes the
basic principle for loading software and data to the host through the BAM.
I. The Communication Connections Related to Loading
The communication connections inside the frame and between the BAM and the frame
are shown in Figure 3-7.
3-16
BAM
172.20.200.0 172.30.200.0
Network Network
adaptor A adaptor B
LAN Switch 0 LAN Switch 1
OSTA frame
H H
S S
Slot 7 C C Slot 9
I I
S S
I I
Slot 6 U U Slot 8
I I
Back half of frame
Front half of frame

I C S S F B
F D M M C S
M B U U C G
I I I I U I
Left half of frame Right half of frame
Figure 3-7 The communication connections related to loading
The communication connection between the BAM and the frame has two planes. One
is “network adaptor A -> LAN Switch 0 -> the HSCI in slot 9”, the other is “network
adaptor B -> LAN Switch 1 -> the HSCI in slot 7”.
3-17
Note:
Because the active/standby configuration is adopted by the network adaptor of the
BAM, LAN Switch and the HSCI in the frame, the system does not have special
requirement for the connection between the active/standby network adaptor and the
active/standby LAN Switch and the connection between the active/standby LAN Switch
and the active/standby HSCI. For example, the connection between the BAM and the
LAN Switch can be “network adaptor A→LAN Switch 0 and network adaptor B→LAN
Switch 1” or “network adaptor A→LAN Switch 1 and network adaptor B→LAN Switch 0”,
as shown in Figure 3-7.
1) Inside the frame, each HSCI provides two network ports connecting to different
SIUIs. Each SIUI connects to its corresponding SMUI through internal cables.
2) Physically, the shared resource bus on the mother board of the frame is divided
into segment A and segment B. Segment A is located in the left half of the frame,
and controlled by the HSCI in slot 9 (not shown in the figure); segment B is located
in the right half of the frame, and controlled by the HSCI in slot 7. Generally, after
initialization of the frame, the active HSCI connects the two halves of the shared
resource bus to a logically complete one, as shown by the broken lines in
Figure 3-7.
II. Loading Process
1) After the frame is powered on or reset, the boards in the frame will run the BIOS
program to initialize automatically. After initialization, the system will load the
SMUI.
2) The system will decide one of the two SMUIs in each frame to be active. The
system also set the HSCI that is in the same half-frame with the standby SMUI to
be the active HSCI.
3) The active and the standby SMUIs read frame number and slot number from the
corresponding SIUI, set the MAC address and IP address of the FE port on the
SIUI, and send loading request to the BAM.
3-18
Note:
z The communication structure of dual planes ensures that the system configures two
IP addresses for each SMUI board, one of which is located in the “172.20.xxx.xxx”
network segment, the other one is located in the “172.30.xxx.xxx” network segment.
z During loading, The SMUI uses the temporary IP address. The two SMUIs have
different IP addresses. The IP addresses of the SMUI in slot 6 are 172.20.frame
number.100 and 172.30.frame number.100. The IP addresses of the SMUI in slot 8
are 172.20.frame number.101 and 172.30.frame number.101.
z After loading, the system will re-configure the IP address of the SMUI. The two
SMUI have the same IP address: 172.20.200.module number and
172.30.200.module number.
4) When the BAM receives the loading request from the SMUIs, it first finds out the
loading mode of the SMUIs. Here, the SMUIs load both data and software from the
hard disk of the BAM through the MML command settings. When the configuration
is normal, the active and standby SMUIs will start loading at the same time.
5) When the active SMUI successfully completes loading and is working normally, it
will initialize and connect the two halves of the shared resource bus to a logically
complete one.
6) When the other boards detects through the shared resource bus that the active
SMUI is normal, they will send loading requests to BAM, and BAM will start the
loading of these boards in parallel.
III. Communication Path for Loading
In Figure 3-7, when all the devices are working normally, suppose the SMUI in slot 6 is
decided to be the active SMUI and the HSCI in slot 9 is the active HSCI. The
communication paths for loading software and data on the boards of the frame from the
BAM are:
z Active SMUI: BAM network adaptor A→LAN Switch 0→HSCI in slot 9→SIUI in
slot 6→SMUI in slot 6.
z Standby SMUI: BAM network adaptor B→LAN Switch 1→HSCI in slot 7→SIUI in
z Service boards: BAM network adaptor A→LAN Switch 0→HSCI in slot 9→SIUI in
slot 6→SMUI in slot 6→shared resource bus→service board.
In Figure 3-7, when the LAN Switch 0 is faulty, the system will decide the SMUI in slot 8
to be the active SMUI and the HSCI in slot 7 is the active HSCI. The communication
paths for loading software and data on the boards of the frame from the BAM are:
z Active SMUI: BAM network adaptor B→LAN Switch 1→HSCI in slot 7→SIUI in
3-19
z Standby SMUI: BAM network adaptor B→LAN Switch 1→HSCI in slot 7→SIUI in
z Service boards: BAM network adaptor B→LAN Switch 1→HSCI in slot 7→SIUI in
slot 8→SMUI in slot 8→shared resource bus→service board.
When only one LAN Switch or one board is faulty, you can determine the
communication paths for loading software and data for all boards in the frame
according to the above description.
Actually, it rarely happens that two or more than two devices are faulty. Therefore, the
SoftX3000 is quite reliable.
3.5.2 Data Operation
When you conduct data operations on a workstation, the BAM analyzes the associated
commands, and the configuration management service stores the modified data to the
database of the BAM and converts the data format. Subsequently, the Exchange
service on the BAM sends the successfully converted data to the data management
system of the SoftX3000 which will update the related service modules. The data files
sent from the BAM to host include DB_?.DAT, in which ? indicates the associated
module number (2–252). Different service processing modules are loaded with different
data files. Data operations include data format conversion, data setting, Cyclic
Redundancy Check (CRC), data backup, and automatic format setting.
I. Data Format Conversion
The BAM converts data in the operation and maintenance-oriented format to a suitable
format which can be identified and processed by service processing modules. This is
data format conversion. You can choose to convert part or all of modified data. The
service processing modules can only load the data after a format conversion. In the
following cases, data format conversion is required.
z Operator re-generates a data file.
z When you add, delete, or modify data by running MML commands at client, the
data management console will automatically activate the format conversion
command to update the corresponding data file.
z On receipt of a format conversion command from the traffic measurement console,
the BAM carries out the conversion and writes the converted data to the data file of
the corresponding module.
II. Data Setting
The data setting is that the BAM sends the data in a converted format to the
corresponding module of the SoftX3000.
After you have modified the data in the BAM, you should start data setting. The time for
data setting depends on the connection state between the BAM and host as well as the
formatting switch. If the BAM and host are in the online state (connected), the system
3-20
will automatically start data setting when you modify the data in the BAM. If both are in
offline state (disconnected), the system will start data setting when they are in online
state. Data setting is required in the following cases:
z When you add, modify, or delete data by running MML commands, BAM will
automatically start data setting.
z When you run FMT command to request BAM start data setting.
All data sets are from data files. Multiple clients can set data in BAM simultaneously. At
present, data setting is only applicable to active boards. The data on standby boards
will be synchronized at the equipment side. The BAM carries out data setting on both
active and standby WCDBs. In addition, you can choose to send part or all of data to a
specified module when timeout or a CRC result reveals the data inconsistency.
III. CRC Check
To ensure the data consistency between the BAM and the host, the maintenance
management subsystem adopts CRC technique.
Periodically, the BAM sends a CRC request to the host to start the data check table by
table. Through a CRC check, you can know whether a data table is consistent between
the BAM and host. When finding data inconsistency, the BAM will originate a data
setting request to the host. If the number of data setting attempts exceeds a specified
value, the BAM will generate an alarm. In this case, you can set or load data to restore
the data consistency.
IV. Data Backup
To guarantee the security of data, the system provides a function to back up the BAM
database files, registration files and configuration files to a specified folder. In the event
of a system failure, you can restore data from the backup of the database files and
configuration files. There are two ways to carry out data backup:
z Automatic backup of BAM data
z It is applicable to a relatively small volume of traffic. During the execution of the
backup command, the system does not accept any service requests.
z Manual backup of BAM data
You can back up the system data either by running the MML command BKP DB or
using the DTS Import/Export Wizard of SQL Server.
V. Automatically Resume Format Conversion
In case that the BAM is powered off exceptionally due to power supply failure, some
format conversion and data setting tasks might still be unfinished. When the BAM
restarts, the system checks whether there are uncompleted tasks. If so, the system will
automatically resume the format conversion and data setting tasks.
3-21
3.6 Software Patch Management

Sometimes adaptive and corrective modifications to the host software are required
during the running of the SoftX3000. For example, you need to eliminate some found
defects from the system, and add some new features. Traditionally, you halt the running
of the host software to upgrade. However, it affects services provisioning. By patching
the host software, the software can be upgraded in the in-service state, which does not
affect the quality of the provided communication services.
3.6.1 Basic Concepts
I. Patch
A patch is a segment of executable program codes, used to replace the codes to be

corrected or updated in the host software.
II. Patch Number
The patch number is the number of the patch generated in time sequence. For example,
patch number 1 and patch number 2.
III. Patch Area
The patch area is a dedicated area in the memory of the SoftX3000 used to store
patches only.
IV. Universal Patch
A universal patch is a software patch provided to solve common problems encountered

in multiple offices running the same base version.
V. Dedicated Patch
A dedicated patch is a software patch provided to solve unique problems encountered

in an individual office.
VI. Patch File
A patch file is a file accommodating multiple patches of the same base version.
3.6.2 Features of Software Patch
I. Version-Specific
A software patch is designed for a particular software version only. A patch for base
version A cannot serve for base version B. When a base software version is patched for
specific times, the version of the software needs to be upgraded. That is, all software
patches of the original version are merged into a new version, and software patches of
the new version are released separately.
3-22
II. Multiple Patches Comprising One Patch File
One or more patches may be released whenever a problem is encountered. Depending

on their creation time, the patches are numbered from 1 to, theoretically, 65535.
Actually, the maximum patch number is limited by memory space.
A patch file includes all the patches pertaining to a particular software version. Patches
are released in the form of patch file.
The corresponding patch description file is released along with the patch file. The patch
description file details all the patches, such as the problems to be eliminated by that
patch file, as well as some preventive measures.
III. Simple Patching Operations
To patch the current software version in the in-service mode without interruption of the
running of the system, what maintenance personnel need to do is to execute a simple
MML command.
Caution:
Because patching software in the online mode has a direct effect on the running of the
central processor, only the operator with system administrator authorities is allowed to
perform patching operations.
IV. Self-healing Ability
In the event of an exception, such as fault of the power supply of the system or system
restart, a patched board in SoftX3000 can be automatically restored to the original
patching state without manual intervention.
3.6.3 Architecture of Software Patch
A software patch is composed of the following three parts: Patch creation tool,
background patch management module and host patch management module.
I. Patch Creation Tool
The patch creation tool organizes one or multiple patches to create a patch file based
on a particular software version. The patch file is created in the offline mode.
II. Background Patch Management Module
The background patch management module is a component of the BAM software. The
background patch management module provides the following functions.
3-23
z Providing command interfaces for operator to manage and maintain patches.

z Maintaining the consistency of the module patch configuration table and the
module patch state table with SoftX3000, according to patch commands typed by
operator and information returned from SoftX3000.
z Transferring patch files to SoftX3000.
z Generating corresponding patch reports.
III. Host Patch Management Module
The host patch management module is a component of the SoftX3000 (host) software.
The host patch management module provides the following functions.
z Processing patch related maintenance interfaces and related commands from the
BAM.
z Maintaining the consistency of the module patch state table with the BAM,
according to patch commands typed by operator.
z Receiving patch files, and detaching them to the patch area of SoftX3000.
z Writing patch files to a flash memory.
z Restoring patches whenever the system restarts.
z Synchronizing patches of standby boards with respectively active boards.
3.6.4 Implementation of Software Patch
The service maintenance system provides a number of simple commands for operator
to patch software or remove patches in the online mode, such as LOAD, ACT, DEA,
RUN, and RMV.
A host software patch may be in one of the four states, namely idle, deactive, active,
and run.
z Idle: The initial state which indicates that the memory does not contain the
software patch.
z Deactivated: The software patch has been loaded to the patch area, but not been
activated. The patch cannot be implemented.
z Activated: The patch has been activated and can be implemented. This is a
commissioning state.
z Run: The patch is formally launched into service. A patch in run state cannot roll
back to the previous state. The only approach is to remove the patch.
The state transition for patch is illustrated in Figure 3-8.
3-24
LOAD
Idle Deactive
RMV
RMV ACT DEA

RMV
RUN
Run Active
Figure 3-8 Patch state transition
The active state is a temporary state. A patch in this state is commissioning. If you
observe a period of time and find the system commissioning can be conducted normally,
please transit it to the run state by using the RUN command. If you find the patch still
has defects, you can execute the DEA command to transit it to the deactive state.
Whenever the system restarts, only the patches in the run state will be restored. The
patches in the active state will not be restored because it is a temporary state.
If certain patches are no longer required, you can execute the RMV command to delete
them, that is, transit their respective state to be idle.
3-25
U-SYS SoftX3000 SoftSwitch System Chapter 4 Charging System
Chapter 4 Charging System
4.1 Basic Concepts

A complete process of charging a particular subscriber or trunk refers to a process from
off-hook of the calling party or incoming of a trunk call to the generation of a bill for the
particular subscriber. The entire process falls into two stages:
z SoftX3000 charging
z Offline billing or online billing
4.1.1 SoftX3000 Charging
The SoftX3000 records all information on each call, and generates a CDR or a metering
bill based on pre-determined charging data. A bill refers to a data unit which is
generated in SoftX3000 for a call and is used to accommodate original charging
information in a particular format.
4.1.2 Offline Billing or Online Billing
I. Offline Billing
Offline charging is to analyze and process bills, and calculate with defined charging
regulations the specific fee of each subscriber or trunk during a period of time. This
process requires no real-time operation, so it is carried out on a dedicated device in the
offline mode. Generally, a billing center is responsible for offline charging.
II. Online Billing
The online billing system is responsible for providing, in the shortest time, call bills
generated by SoftX3000 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.
Note:
The SoftX3000 charging system is implemented in the online mode. The online billing
functions can be achieved either by the BAM or through the iGWB.
4-1
4.1.3 Bill Type
Depending on different charging methods, call bills fall into two categories, namely
detailed bills and metering bills. In addition, a single office may have statistical bills
used for the statistics of charging information pertaining to a particular type of calls.
I. Detailed Bill
A detailed bill records all charging details of a conversation in a particular format, such
as the calling and called party, the conversation duration, and the service attribute.
Usually, detailed bill is applicable to toll calls.
According to different applicable situations, detailed bills are classified into five types:
ordinary bill, credit card bill, complaint bill, free call bill and alarm bill.
z Ordinary bill
Applicable situation: Generally detailed bills charging subscribers and trunks are
ordinary bills.
In the case of centralized charging, two ordinary bills are generated. One charges the
incoming trunk. The other charges the subscriber (with the calling number provided by
the lower office). The charging office is of “centralized charging” mode.
z Credit card bill
Applicable situation: Campus card users and company card users.
When a user makes a call by using a card number, the charging number type is
“account card category” or “VISA card”. By default, a third party is charged for the call.
The calling number is the card number. The called number is the telephone number
dialed by the credit card user. The charged number is the account of the card used by
the user.
z Complaint bill
Applicable situation: Subscriber wants to get the details of conversations.
No matter whether a call is charged in a detailed bill or a metering bill, a complaint bill is
generated if the calling or called party (subscriber or trunk) requests it. The difference of
compliant bill from ordinary bill is the “charging complaint” flag is enabled.
z Free call bill
Applicable situation: Details of free calls are recorded.
A free call bill is generated whenever a free call is made, in spite of the charging
attribute of the subscriber or trunk. The difference of free call bill from ordinary bill is the
“charging category” is set to Free.
4-2
Note:
z A free call bill is generated in the following cases:
z The “charging category” in the subscriber attribute is set to Free.
z The “payer” in the associated charging case is set to Free.
z An answer signal, no charge (ANN) message from the opposite office is received.
z Alarm bill
Applicable situation: The SoftX3000 generates an alarm bill because charging data is
configured incorrectly.
The format of an alarm bill is the same as that of an ordinary bill. An alarm bill records
the details of the calling and called number and the duration of the conversation. Other
charging information will also be recorded if provided. The difference of alarm bill from
ordinary bill is the “charging category” is set to ALARM. In addition, partial bill contents
are always empty.
According to the contents of an alarm bill, operator can locate the problem of the
charging data. Because the basic call information is recorded in an offline billing
process, an alarm bill can be based to calculate the conversation fee.
II. Metering Bill
SoftX3000 provides 20 charging meters for each subscriber or trunk group to

accumulate the charging meter counts of different types of calls. Usually the charging
meter is applicable to intra-office calls.
Whenever a call is made, SoftX3000 converts call factors such as call distance,
conversation duration, and service attribute to an equivalent metering count, and
accumulates the count on the charging meter of the subscriber or trunk. Periodically, all
counts of a charging meter accumulated during a defined time period are output and
the value of the charging meter is cleared to zero. SoftX3000 uses a metering bill to
store the accumulation of metering counts pertaining to the same type of calls for each
subscriber or trunk group.
III. Statistical Bill
In the format of charging meter, a statistical bill records the statistics of charging
information pertaining to the same type of calls during a specified period of time.
A single office provides six statistical tables: intra-office metering statistical table,
outgoing metering statistical table, incoming metering statistical table, transit metering
statistical table, free call statistical table, and trunk duration statistical table.
z Intra-office metering statistical table, outgoing metering statistical table, incoming
metering statistical table, and transit metering statistical table: Carries out the
statistical analysis of respective call times and metering counts.
4-3
z Free call statistical table: Carries out the statistic analysis of call times and
duration of all free calls in the local office.
z Trunk duration statistical table: Carries out the statistic analysis of call times and
duration of calls through incoming trunks (incoming and transit) and outgoing
trunks (outgoing and transit), used for charge audit between gateway offices.
4.2 Architecture of Charging System

4.2.1 Logical Architecture of Charging System
Figure 4-1 shows the logical architecture of the SoftX3000 charging system.
Call control
module
iGWB Billing center
Ticket pool BAM
FCCU/FCSU
SoftX3000
Figure 4-1 Logical architecture of billing system
I. Call Control Module of FCCU/FCSU
In SoftX3000, the call control module is responsible for generating bills.
II. Bill Pool of FCCU/FCSU
The bill pool stores the bills generated by the call control module on the local board.
The active FCCU/FCSU periodically synchronizes the bills to the standby board against
possible data loss due to board failures to the utmost extent.
The SoftX3000 defines two thresholds for the used space of the bill pool. Whenever the
used space of the bill pool reaches the first threshold (70%), an alarm will be generated;
whenever the used space exceeds the second threshold (100%), an alarm will be
generated and calls will be restricted.
III. iGWB
The iGWB is resident between SoftX3000 and the billing center, responsible for
receiving, pre-processing, and buffering bills, as well as providing billing interface
functions.
4-4
Note:
The bill sending process in the bill pool of the FCCU/FCSU is automatically triggered by
the internal timer of the SoftX3000. When the FCCU/FCSU detects that there are bills
in the bill pool, it will send the bills to the iGWB in real time.
IV. BAM
The BAM stores the FCCU/FCSU CENTREX bill when the bill pool is about to overflow.
When the communication between the FCCU/FCSU and IP CENTREX console
(U-PATH) is abnormal, the IP CENTREX console cannot take bills out of the
FCCU/FCSU CENTREX bill pool. When the CENTREX bill pool is about to overflow,
the FCCU/FCSU will sent the bills to the BAM for storage.
V. Billing Center
The billing center carries out billing functions in the offline mode and outputs the final
communication fee lists for subscribers.
4.2.2 Functioning Process of Charging System
A functioning process of the SoftX3000 charging system is illustrated in Figure 4-2.
B Ticket pool H
F Centrex ticket S
U-PATH
I pool C
I Meter soft table I
LAN Switch in BAM

integrated
FCCU/FCSU
configuration
Basic frame 0 cabinet
Ticket pool H
Centrex ticket S Billing
pool C iGWB
center
Meter soft table I
FCCU/FCSU
Expansion frame n
Figure 4-2 Functioning process of the SoftX3000 billing system
Whenever a call ends, the FCCU/FCSU generates charging information and stores the
information in the bill buffer of the local board. The FCCU/FCSU has a memory of 180
4-5
MB. Each bill is 250 bytes in length. Each pair of active/standby FCCU/FCSU has a
capacity of 720,000 bills. The bill buffer of the FCCU/FCSU is composed of the
following three components:
z A host bill pool: Stores all bills to be sent to iGWB.
z A Centrex bill pool: Stores the detailed bills and metering soft table bills to be sent
to Centrex console—U-Path.
z A metering soft table: Stores metering counts of both charging meters and
statistical tables.
Note:
Generally the FCCU/FCSU bill pool does not store bills. The FCCU/FCSU sends the
generated bills to iGWB or CENTREX console in real time. When the communication
between FCCU/FCSU and iGWB becomes abnormal, the FCCU/FCSU will begin to
store the bills.
2) The various detailed bills are directly stored in the bill pool of the corresponding
FCCU/FCSU according to the module number of the FCCU/FCSU.
3) Charging information in the metering mode is accumulated on the metering soft
table of the respective subscriber or trunk. The system updates the metering soft
table of the FCCU/FCSU either periodically or immediately. The system converts
the metering counts of each subscriber or trunk to an equivalent bill and stores the
bill in the bill pool.
4) For bills generated by CENTREX users, there are two bill generation modes
differed by the configuration commands executed.
z If you execute MOD CXGRP to modify CENTREX attributes, and select any other
values except for NOT SEND for the parameter Send bill to console (for instance,
DETAILED BILL), on call completion, the FCCU/FCSU will generate two bills for
the call. One is stored in the bill pool of the host and will be sent to the iGWB in real
time, the other is stored in the CENTREX bill pool and will be sent to the
CENTREX console for further processing.
z If you execute MOD CXGRP to modify CENTREX attributes, and select NOT
SEND for the parameter Send bill to consol, on call completion, the FCCU/FCSU
will generate one detailed bill in the host bill pool. The detailed bill will be sent to
the iGWB, and there will be no bill generated in the CENTREX bill pool.
5) The bills in the host bill pool on the FCCU/FCSU are sent in real time to the iGWB
through the shared resource bus, the HSCI and the LAN Switch, and stored in files.
For the detailed bills stored in the CENTREX bill pool on the FCCU/FCSU, after
the CENTREX console sends a request to the host to fetch bills, the FCCU/FCSU
sends the detailed bills to the CENTREX console through shared resource bus,
IFMI, BFII, and LAN Switch.
4-6
Caution:
z When the communication between the U-PATH and the FCCU/FCSU is abnormal
and the bills in the FCCU/FCSU CENTREX bill pool are about to overflow, the
charging system will send the bills to BAM for temporary storage. When the
communication between the U-PATH and the FCCU/FCSU is restored, and the
U-Path sends bill-fetching requests to the FCCU/FCSU, the FCCU/FCSU will
retrieve the bills stored in BAM, and sends them to the CENTREX console for
further processing.
z For the bill processing details in the CENTREX console, refer to U-SYS U-PATH
Enterprise Communication Assistant User Manual.
6) The iGWB performs processing on the original bills including bill sorting (such as
detailed bills and metering bills) and format conversion (from a binary format to a
text format). After being processed, final bills are generated and stored in specific
folders (or paths). For example, ordinary bills and hotline bills are stored in
different paths. The processing of the iGWB on bills is shown in Figure 4-3.
FCCU/FCSU
SoftX3000
ticket pool
Original ticket
Ticket Storing original

receiving tickets
Ticket sorting
Format
Storing final bills Sending bills
conversion
iGWB
Final bills
Billing center
Figure 4-3 Bill processing diagram of iGWB
4-7
Note:
z The active and standby iGWBs and SoftX3000 are interconnected in dual planes.
That is, there are 4 communication channels among the active and standby SMUIs,
the active and standby LAN Switches, and the active and standby iGWBs. The
iGWBs and the SMUIs are able to judge the current state of the communication
channels. Interruption of any of the channels does not break the normal
transmission of bills.
z An active iGWB and a standby iGWB are configured in the system The system
adopts dual-host and real-time backup in network backup mode to prevent possible
loss of charging data due to a single-host failure.
z After being sorted, the original bills whose formats do not need to be converted are
stored as the final bills directly.
7) The iGWB and the bill collector at the billing center communicate with each other
through the standard File Transfer Protocol (FTP) or File Transfer Access &
Management Protocol (FTAM) to guarantee the reliable transfer of final bills to the
billing center.
Note:
If the FTP is used, the iGWB functions as the server and the bill collector as the client.
If the FTAM is used, the iGWB functions as the responder and the bill collector as the
initiator, which is similar to the FTP communication mode.
4.3 Bill Storage

There are two categories of bills:
z Original bills
z Final bill
The original bills are those sent from the SoftX3000 to the iGWB. Each original bill is
250 bytes in length. The first four bytes are used as transmission overhead, so the valid
length is 246 bytes.
The final bills are those sent from the iGWB to the billing center. Each final bill is 140
bytes by default, and can be adjusted to 118 bytes like a bill of an ordinary switch.
On receipt of original bills from the SoftX3000, the iGWB stores them, sorts them, and
converts them into a particular format known as final bills. The iGWB sorts the bills
according to its own format library, which locates in C:\iGWB\format.
4-8
The following sections will focus on the generation, naming convention, and storage
modes of the original bills and the final bills.
4.3.1 Bill Storage Directory
The default bill storage directory on the iGWB server is described as follows.
D:\frontsave Storing original bills
E:\backsave Storing final bills
D:\other\mml Storing user information files used by the MML server
D:\other\log Storing log files
D:\other\alarm Storing history alarms
4.3.2 Storage of Original Bills
The iGWB receives the original bills (250 bytes) from the SoftX3000, removes the
transmission overhead (4 bytes), and stores them under two folders: D:\frontsave and
E:\backsave.
I. Original Bill Directory Structure
The original bills are stored under a subdirectory named according to the product name.
Suppose the name of the subdirectory is X3KF in this case.
The directory structure for original bill files is fixed. See Figure 4-4.
4-9
D:\FrontSave
X3KF
Date
Origianl ticket file
Date
Figure 4-4 Directory structure for original bill files
The original bills are stored in folders named by date. For example, all original bill files
generated on January 1st, 2002 are stored in the folder named 20020101. By default,
the iGWB stores the original bill files of the last seven days.
The length of an original bill file can be configured as along as it does not exceed the
maximum value. The size of each original bill file is fixed to 3 MB. The original bill files
are named in the format of b + ten digits of file serial number +.bil. For instance,
b0000000001.bil, b0000000002.bil.
II. Format of Original Bill
The contents of original bills are stored in original bill files. Each original bill has the
same length and is in the same format. The SoftX3000 provides the following types of
original bills for the iGWB Refer to Appendix A for the format of these bills. Format of
original bill:
z Fixed network intelligent bill
z Fixed network ordinary detailed bill
z Fixed network metering bill
z Fixed network metering statistical bill
z Fixed network trunk duration statistical bill
4-10
z Fixed network free call statistical bill

z Supplementary service bill
4.3.3 Storage of Final Bills
The directory structure for final bill files is shown in Figure 4-5, which can be configured.
E:\BackSave
X3KF
Channel 1
Date
Final bill file
Final bill file
Date
Final bill file

Channel n
Final bill file
Date
Final bill file
Final bill file
Date
Final bill file
Final bill file
Figure 4-5 Directory structure for final bill files
Note:
Final bill files can also be stored under channels directly. It is recommended to store
final bill files under the directory of channel and date.
4-11
I. Channel
Bill files satisfying particular conditions are stored in the same channel. For example,
bill files of different types can be stored in different channels, that is, each type of bills
corresponds to one channel.
II. Final Bill File Name
The final bill files are named in the format of prefix + file serial number + . + suffix. For
instance, b00000001.dat.
z Prefix
The optional prefix can be any string of characters. Usually the office name is used. By
default, it is the character b.
z File serial number
The mandatory file serial number is an incremental number from 00000001 to
99999999.
z Suffix
The suffix can be configured. The default value is dat.
III. Final Bill File
The generation of a final bill file depends on two conditions— the length of file and the
generation duration of file. Both conditions take effect simultaneously and equally.
Calculated from the start time of the generation of a final bill file, the file will be closed
whenever the file length reaches its upper limit or the generation duration reaches its
upper limit. Subsequently, a new final bill file will be created.
A final bill file contains one or more final bills, as shown in Figure 4-6.
Final bill 1 Final bill 2 Final bill 3 Final bill 4 Final bill n
Figure 4-6 Format of final bill file
Note:
After the bill collector of the billing center has collected a final bill file, the file is not
removed from the iGWB because it is still used for routine query purposes. The iGWB
will remove that final bill file only after the file expires. By default, the iGWB stores the
final bill files of the last seven days.
4-12
U-SYS SoftX3000 SoftSwitch System Chapter 5 Alarm System
Chapter 5 Alarm System
5.1 Overview of Alarm System

Alarm management is a part of the fault management system in the OMC. The fault
management system includes a complete set of intelligent functional software which is
able to detect, isolate and correct the exceptional running of the managed device
modules. Whenever a fault which might affect services occurs to SoftX3000, the
corresponding module generates an alarm and the alarm management module reports
the alarm to the operator. The reported alarm is helpful for the operator to take
appropriate measures to eliminate the fault.
5.2 Structure of Alarm System

The alarm system is composed of two subsystems: the fault detection subsystem and
the alarm generation subsystem.
I. Fault Detection Subsystem
The running of the devices is monitored through the hardware detection and the
software detection. Information of fault, if encountered, is reported in time so that the
operator can handle the fault effectively. The purpose is to ensure the secure running of
the equipment.
1) Hardware detection
Hardware detection as follows is implemented by individual boards.
z Running state of the local board (normal/abnormal, active/standby)
z (Multi) frame synchronization/out-of-synchronization
z Clock
z Channel faults
z Online/offline
2) Software detection
Through software detection, logic errors beyond the control of hardware detection can
be found.
z Self-loop test of board
z CRC check
z Memory check
z Data consistency check
5-1
II. Alarm Generation Subsystem
The alarm generation subsystem collects information about the encountered fault and
generates a detailed record of alarm in various tables, to notify maintenance personnel
for necessary handling purposes.
The alarm generation subsystem is composed of an alarm module on SoftX3000, an
alarm server module on the BAM, an alarm console, and an alarm box. See Figure 5-1.
The alarm module on SoftX3000 collects alarm information reported from other
SoftX3000 modules and the iGWB, and then transmits the collected information to the
BAM. The alarm server module on the BAM analyzes information about all alarms
(including those generated by the BAM) and stores the information. In addition, the
alarm server module indicates the alarm box to generate audio/visual alarms, and
meanwhile reflects the alarm details and troubleshooting recommendations on the
alarm console of the workstation.
Alarm
Other module management
WS
system
Alarm module Alarm process

Alarm box
Host BAM
Figure 5-1 Alarm generation subsystem
The broken lines indicate the connections of the alarm box which can be either
connected to the BAM or connected to the alarm workstation.
Besides from the alarm box and the alarm console, operation and maintenance
personnel can also obtain alarm information in the following ways:
z Device penal on the workstation
z Status indicators on each board: For details about the meanings of board
indicators, refer to Chapter 2 of this manual or help pages of the maintenance
system.
5.3 Alarm Categories and Alarm Levels

5.3.1 Alarm Categories
An alarm report output from the alarm console contains alarm category which indicates
the nature of the alarm. There are three categories of alarms: fault alarms, recovery
alarms, and event alarms.
5-2
z Fault alarms: alarms generated due to faults of hardware components or

exceptions of significant functions.
z Recovery alarms: Alarms generated when the faulty components or abnormal
functions are recovered. Each fault alarm has a recovery alarm.
z
Event alarms: Used for indication purposes. Each event alarm does not have a
fault alarm or recovery alarm corresponding to it.
5.3.2 Alarm Levels
Alarm levels identify the severity of alarms.

z Critical alarms: Fault alarms and event alarms which will probably cause the
breakdown of the whole system, such as failures and overload of key boards
including the SMUI, the SIUI, the HSCI, the CKII, and the CDBI.
z Major alarms: Fault alarms and event alarms of boards or connections which will
probably affect a part of the whole system, such as failures of the FCCU/FCSU,
the IFMI, the BSGI, the MSGI, the MRCA (Media Resource Control Unit), and the
MRIA (Media Resource Interface Unit), and failures of communication links.
z Minor alarms: Fault alarms and event alarms which are associated with the
normality of the running of boards or connections, such as failures of the ALMI and
PCM.
z Warning alarms: Fault alarms and event alarms which will probably not affect the
performance of the whole system, such as board switchover and restoration.
5.4 Alarm Box and Alarm Console

5.4.1 Alarm Box
Designed in an open structure, the alarm box provides powerful functions and
convenient maintenance as follows:
1) The alarm box provides four levels of alarms in both visible and audible ways
accurately in real time: critical alarms, major alarms, minor alarms, and warning
alarms. The alarm display is straightforward, and the alarm tone is clear.
2) The alarm box can be used in good coordination with the alarm console, which is
helpful to make full use of alarm console resources and is also convenient for
operator to perform operations. The alarm box only provides information about
alarm levels. The alarm console provides the details of alarms. In that way, the
resources of the alarm box and the alarm console can be used in the most
reasonable and effective manner.
3) The alarm box supports flexible networking models. According to the actual
situations, the alarm box can be connected to either the BAM or the alarm
workstation.
5-3
4) The alarm box provides powerful serial port communication functions. There are
eight serial ports designed in the alarm box: four RS-232 serial ports and four
RS-422 serial ports. A maximum of five serial ports are available for external
communications. The communication distance of the RS-232 serial ports can
reach 80 meters. The communication distance of the RS-422 serial ports can
reach 100 meters.
5) The alarm box provides the system-down-messaging function. When the system
breaks down, a system-down message is reported to the alarm box.
6) The alarm box provides 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 muted. However alarm sound for critical alarms
cannot be muted for the purpose of ensuring the normal running of the system.
7) The alarm box provides remote alarming and remote alarm sound control
functions. By connecting to a 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. The remote alarm sound control
can be placed a maximum of 30 meters away from the alarm box. With both
functions, operator can operate and maintain the alarm box in a remote way.
8) The alarm box provides simple fault locating methods and convenient
maintenance operations. Through maintenance serial ports, faults of the alarm
box can be located quickly and exactly.
9) The alarm box supports a variety of power supplies including Alternating Current
(AC) 220 V, AC 110 V and Direct Current (DC) -48 V, to meet international power
supply needs.
10) The reliability, security and electromagnetic compatibility (EMC) features of
SoftX3000 have passed all environmental tests, EMC tests, and electromagnetic
interference (EMI) tests.
11) The small alarm box appears simple. Alarms are displayed graphically. It is easy
to install an alarm box.
For more information about the alarm box, refer to Universal Alarm Box User Manual
delivered along with the alarm box.
5.4.2 Alarm Console
The alarm box only provides visible and audible alarm level information. The alarm
console on the workstation provides the details about alarms.
The frequently used alarm console is very significant for maintenance personnel. To
correctly reflect SoftX3000 alarms in real time, the alarm console provides alarm view,
query and management functions, as follows.
z Real-time view and conditional real-time view of current alarms.
z Composite query of a particular category of alarms and dynamic update of
displayed results.
5-4
z Detailed interpretation of alarm records and real-time display of handling methods.

z Printing of currently displayed alarms (in the alarm interpretation format) and
printing in a real-time way.
z Automatic paging message sent to maintenance personnel whenever an alarm is
generated.
z Mute and reset functions and indicator operations.
5.5 Alarm Reporting Paths

5.5.1 Hardware Alarm Reporting Paths
All boards used in SoftX3000 are intelligent. For example, all boards are able to monitor
respective running state, running conditions and external interfaces. The boards are
also capable of testing and indicating respective state and reporting exceptions to
upper-level devices. The upper-level devices can automatically monitor the running
state of underlying devices. Whenever exceptions are detected, the upper-level
devices can report to further-upper-level devices and meanwhile take necessary
handling measures, such as blocking channels and switching active/standby boards.
I. Alarm Path for Service Processing Frames
Hardware fault information and alarm information from the service processing frame
are reported through the path as shown in Figure 5-2.
PDF
RS485 serial port
H S B F F I B M C
S I F C C F S S D
C U I C S M G G B
I I I U U I I I I
Shared resource bus Shared resource bus

S
E C M
P K U
I I I
I I A Backplane U
L P
U W
I R
Serial bus Serial bus
LAN
Emergency
BAM WS Alarm box
workstation
Figure 5-2 Alarm path for hardware faults from service processing frame
5-5
z Alarm path for front boards except for the ALUI and the UPWR: After collecting
alarm information from the front boards through the shared resource bus, the
SMUI reports the information to the BAM through the Ethernet for alarming
purposes. The alarm information will be displayed on the alarm console on the
workstation, and audio/visual alarms will be generated on the alarm box.
z Alarm path for back boards: For the back boards (the HSCI, the SIUI and the BFII)
without processors, the corresponding front boards collect respective state of
these back boards and subsequently report to the SMUI through the shared
resource bus. For the back boards (the EPII, the CKII and the ALUI) with
processors, respective state is directly reported to the SMUI through the serial port
bus on the backplane. After collecting the information about the back boards, the
SMUI reports the information to the BAM through the Ethernet for alarming
purposes. The alarm information will be displayed on the alarm console on the
workstation, and audio/visual alarms will be generated on the alarm box. In
addition, the SMUI delivers the state information of the back boards to the ALUI
through the serial port bus. The ALUI drives the indicators on its front panel to
indicate the state of the back boards. A board may be in the state of “uninstalled”,
“normal” or “abnormal”.)
z Alarm path for the UPWR: The ALUI collects state signals of the power supply
modules through the backplane, and then drives the corresponding indicators on
its front panel to indicate the current state of the power supply modules. In addition,
the ALUI reports the state information of the power supply modules to the SMUI
through the serial port bus. The SMUI reports to the BAM through the LAN Switch
for alarming purposes. The alarm information will be displayed on the alarm
console on the workstation, and audio/visual alarms will be generated on the
alarm box.
Note:
z The ALUI does not provide indicators to indicate the working and in-position state of
the two front UPWRs, but provides indicators to indicate the state of the two back
UPWRs.
z The ALUI collects alarm information of UPWRs through two serial port lines
embedded on the backplane.
II. Alarm Path for Media Resource Frame
Hardware fault information and alarm information from the media resource frame are
reported through the path as shown in Figure 5-3.
5-6
H S M F
S I R C
C U I C
I I A U
Share resource bus
S
Share resource bus
M
U A
U
I L
Backplane P
Serial bus U
W
I MRS frame
R
LAN
S LAN
M
U
I
Emergency Alarm
BAM WS workstation box
Basic frame 0
Figure 5-3 Hardware alarm reporting path for media resource frame
z Alarm path for front boards except for the ALUI and the UPWR: After collecting
alarm information from the MRCAs in the local frame through the shared resource
bus, the SMUI in the media resource frame reports the information to the BAM
through the LAN Switch for alarming purposes. The alarm information will be
displayed on the alarm console on the workstation, and audio/visual alarms will be
generated on the alarm box.
z Alarm path for back boards: For the back boards (the HSCI, the SIUI and the
MRIA), the corresponding front boards collect respective state of these back
boards and subsequently report to the SMUI in the local frame through the shared
resource bus. The SMUI delivers the state information of the back boards to the
ALUI in the local frame through the serial port bus. Consequently, the ALUI drives
the indicators on its front panel to indicate the state of the back boards. (A board
may be in the state of “uninstalled”, “normal” or “abnormal”.) I In addition, the SMUI
in the media resource frame reports the alarm information to the BAM through the
LAN Switch for alarming purposes. The alarm information will be displayed on the
alarm console on the workstation, and audio/visual alarms will be generated on
the alarm box.
z Alarm path for the UPWR: The ALUI in the media resource frame collects state
signals of the power supply modules in the local frame through the backplane, and
then drives the corresponding indicators on its front panel to indicate the current
state of the power supply modules. In addition, the ALUI reports the state
information of the power supply modules to the SMUI in the local frame through
the serial port bus. In addition, the SMUI in the media resource frame reports the
alarm information to the BAM through the LAN Switch for alarming purposes. The
5-7
alarm information will be displayed on the alarm console on the workstation, and
audio/visual alarms will be generated on the alarm box.
III. Alarm Path for Power Distribution Frame
z Alarm path for the power distribution frame in the integrated configuration cabinet:
After collecting alarm information from the power distribution frame through the
RS485 serial port of the SIUI, the SMUI reports the information to the BAM through
the Ethernet for alarming purposes. The alarm information will be displayed on the
alarm console on the workstation, and audio/visual alarms will be generated on
the alarm box.
z Alarm path for the power distribution frame in the service processing cabinet: After
collecting alarm information from the power distribution frame through the RS485
serial port of the SIUI, the SMUI in the bottom expansion frame in the cabinet
reports the information to the BAM for alarming purposes. The alarm information
will be displayed on the alarm console on the workstation, and audio/visual alarms
will be generated on the alarm box.
5.5.2 Software Alarm Reporting Paths
Signaling program cannot interwork with the opposite office. A circuit may transit to a
different state due to operations on the opposite office. Service may fail to be
processed. CPU may be overloaded. All those cases are associated with software
alarms.
Both the SoftX3000 software and the BAM can cause the generation of software alarm.
For the SoftX3000 software modules such as the signaling processing module and the
call control module, their alarms are sent to the alarm module which will transfer the
alarms to the alarm server module on the BAM. For the BAM, its alarms are directly
sent to the alarm server module for further processing.
5-8
U-SYS SoftX3000 SoftSwitch System Chapter 6 Environment Monitoring System
Chapter 6 Environment Monitoring System
6.1 Power Supply System

The power supply system powers the entire SoftX3000. It requires high reliability. The
SoftX3000 adopts dual-circuit backup and point-specific monitoring in the design of the
power supply system.
The power supply system consists of two parts— power introduction module and power
distribution module.
6.1.1 Power Introduction Module
The power introduction module refers to the part from the power distribution frame
(PDF) to the SoftX3000 cabinet, as shown in Figure 6-1.
(2)
-48V1
PGND
BGND
-48V1
-48V1
-48V2
PGND
BGND
-48V2
-48V2
-48V1
PGND
BGND
-48V2
（1 ） GND
GND
PGND
（3 ）（3 ）（3 ）
（4 ）
(1) To DC distributor (2) Power distribution cabinet

(3) SoftX3000 cabinet (4) Protection grounding bus
Figure 6-1 Power Introduction Module
The power introduction module includes the direct current (DC) distributor, the PDF,
and the connection cables.
The DC distributor and the power distribution cabinet are not part of the SoftX3000. It is
required that the power distribution cabinet provide two independent, stable power
supplies. The DC distributor provides two independent –48 V power supplies and one
PGND for each SoftX3000 cabinet. Normally, two –48 V power supplies are both
working. When one is faulty, the other will supply power alone.
6-1
6.1.2 Power Distribution Module
The power distribution module includes the PDF and all internal components of the
SoftX3000 cabinets. There are two types of SoftX3000 cabinet: integrated
configuration cabinet and service processing cabinet. Figure 6-2 shows the differences
in power distribution between the two cabinets.
(1) Integrated configuration (2)Service processing (3) PDF

cabinet cabinet
(4)Basic frame 0 (5) Expansion frame 1 (7) Expansion frame 2
(8) Expansion frame 3 (9) Expansion frame 4 (10) Expansion frame 5
Figure 6-2 Power distribution module
Two channels of -48 V power supply are diverted into a PDF where lightning protection
and overcurrent protection operations are performed. Finally Two groups of three -48 V
power supplies are distributed to the frames in the cabinet. The two groups are working
as hot backup.
In addition, the PDF keeps monitoring the input voltage and the state of distributed
power. It will generate an audio alarm when discovering an exception.
Table 6-1 shows the cable names and their use. Table 6-2 shows the use of six
switches (SW1–SW6) on the panel of the PDF.
6-2
Table 6-1 Number and use of cables on PDF
No. Cable number Cable use

1 9 to 20 Power cables for service frames
2 W2 to W5, W7, W8 Grounding cables for service frames
3 6.7 and 6.8 Power cables for KVM and LCD
4 W11 Grounding cable for KVM and LCD
5 1 and 2 Power cables for LAN Switch
6 W9 and W10 Grounding cables for LAN Switch
7 5.3, 5.5, 6.3 and 6.5 Power cables for BAM
8 W12 Grounding cable for BAM
3.3, 3.5, 4.3, 4.5, 5.4, 5.6, 6.4 and
9 Power cables for iGWB
6.6
10 W13 and W14 Grounding cable for iGWB

11 W1 and W6 Grounding cables for PDF
Table 6-2 The use of switches SW1 to SW6
Cabinet type Component Controlling switches

iGWB0 SW2, SW4
iGWB1 SW1, SW3
BAM SW3, SW4
Integrated LANSwitch0 SW3
configuration
cabinet LANSwitch1 SW2
KVM/LCD SW4
Basic frame 0 SW4, SW5

Expansion frame 1 SW5, SW6
Service Expansion frame 3 SW3, SW4
processing
cabinet Expansion frame 4 SW2, SW3
6-3
Note:
In actual situation, the iGWB0 in the integrated cabinet is the active server with
iGWB(M) as its label; the iGWB1 is the standby server with iGWB(S) as its label.
6.2 Power Supply Monitoring

The power supply monitoring module of SoftX3000 monitors the power supply system
in real time, reports its running status, and generates alarms when detecting faults.
The power supply monitoring module covers the following two aspects: Monitoring PDF
and monitoring the power supply of service processing frame.
6.2.1 Monitoring PDF
Each SoftX3000 cabinet is configured with a PDF, which is monitored by the service
processing frame. Figure 6-3 shows the monitoring relationship of PDF and other
components.
PDF
monitor board
RS485 RS485
SIUI SIUI
SMUI SMUI
to OMC
Service processing frame
Figure 6-3 Monitoring PDF
Here is how the PDF is monitored:

1) The PDF is equipped with a monitor board, which is used to collect the running
status of the PDF.
2) The monitor board provides two RS485 serial ports, one active and the other
standby. Through the external RS485 serial port cables, the active or standby
RS485 serial port connects with the SIUI (COM3 port) of the active or standby
SMUI on the service processing frame.
3) The SMUI analyzes the information collected from the PDF and reports the results
to the maintenance management subsystem. For detected faults, the WSMU
sends alarms to the alarm console and the alarm box.
6-4
Note:
When a cabinet is configured with multiple service processing frames, the lowest frame
monitors the PDF of the cabinet.
6.2.2 Monitoring Power Supply of OSTA frame
The power supply board UPWR of the service processing frame is monitored through
the ALUI of the frame. Figure 6-4 shows the details.
Sevice processing frame

ALUI U U
P P
W W
Power Supply R R
W Status
S
S
M
M
U U U
U
I P P
W W
R R
To OMC
Figure 6-4 Monitoring the UPWR
Each service processing frame is configured with four UPWRs—two at the front and
two at the back. Here is how a UPWR is monitored.
1) The UPWR reports the power supply status to the ALUI through the dedicated
signal channel in the backplane.
2) The ALUI monitors the state (level signal) of the power supply in real time. It
reports the status data to the SMUI. The ALUI also indicates the status of the back
UPWRs through its indicators.
3) The SMUI processes the data reported by the ALUI, and sends the results to the
maintenance management subsystem. When the power supply system is faulty,
the SMUI will generate an alarm to the alarm box.
4) The ALUI has a temperature sensor to monitor the temperature of the frame.
6.3 Fan Monitoring

Each service processing frame is equipped with a built-in fan box. The fan monitoring
module monitors the running status of the fan, and adjusts the rotation speed according
to the temperature of the frame. Figure 6-5 shows the architecture of the fan monitoring
module.
6-5
Service processing
frame Fan box
W
S
S
Monitor
board
M
M
U
U
I
To OMC
Figure 6-5 Fan monitoring
Here is how the fan box is monitored:

1) The fan box is equipped with a monitor board, which is used to collect the running
status of the fan box.
2) The monitor board provides an RS485 serial port to connect to the SIUI of the
SMUI of the service processing frame. In the integrated frame, the serial cable
connects the monitor board and the SIUI within the frame.
3) The SMUI analyzes the information collected from the PDF and reports the results
to the maintenance management subsystem. For detected faults, the SMUI sends
alarms to the alarm box.
4) The maintenance management subsystem can configure the fan box.
6.4 Equipment Room Environment monitoring

The PDF monitors the environment of the equipment room. Figure 6-6 shows the
principle of the equipment room environment monitoring.
PDF
Detection
interface
Sensor
Monitor board
RS485 RS485
SIUI SIUI
Service
processing
frame
SMUI SMUI
To OMC
Figure 6-6 Equipment room environment monitoring
6-6
The PDF has five Boolean value detection interfaces which connect to the temperature
sensor, the humidity sensor, and the smoke sensor.
The reporting path of the equipment room is the same as that of the PDF power status.
6-7
U-SYS SoftX3000 SoftSwitch System Chapter 7 Clock Synchronization System
Chapter 7 Clock Synchronization System
7.1 Introduction
7.1.1 Features
When SoftX3000 provides narrowband signaling to connect with other devices, it is

required to configure the clock system to implement clock synchronization. The
SoftX3000 clock system adopts advanced digital phase-lock loop and reliable software
phase-lock technologies, and has the following features.
1) The system enables stratum-2 clock (including category A and category B),
stratum-3 clock and enhanced stratum-3 clock for choice, which meet the
requirements for DC1, DC2 and DL/DTM.
2) The specifications of the clocks conform to the ITU-T recommendations.
3) The structure can be customized flexibly. The stratum-2 and stratum-3 clocks can
be selected through terminals.
4) The software has powerful functions, such as display, alarm and maintenance and
operation functions. The operators can use the maintenance terminal to control
the reference clock and phase-lock mode.
5) The system has powerful phase-lock capability, and is applicable to different clock
transmission conditions.
7.1.2 Technical Specifications
Table 7-1 shows the technical specifications of the SoftX3000 clock system.
Table 7-1 Technical specifications of the SoftX3000 clock system
No. Item Specification
Lowest Stratum-2 clock: ±4×10-7

accuracy Stratum-3 clock: ±4.6×10-6
Stratum-2 clock: able to synchronize with the
-7
accuracy of ±4×10 .
Pull-in range
Stratum-3 clock: able to synchronize with the
-6
Network accuracy of ±4.6×10 .
1 access
parameter Maximum -10
Stratum-2 clock: 5×10 /day
frequency -8
offset Stratum-3 clock: 2×10 /day
Initial -10
maximum Stratum-2 clock: <5×10 /day
frequency Stratum-3 clock: <1×10 /day
-8
offset
7-1
No. Item Specification

Ideal
working MRTIE≤1ms
status
MRTIE (ns) ≤ a×s + (1/2)×b×s2+ c

Long-term where, s indicates time with the unit as
2 phase second. The unit of MRTIE is nanosecond
change (ns).
Hold working
status Stratum-2 clock:
a=0.5 b=1.16×10-5 c=1000
Stratum-3 clock:
a=10 b=2.3×10-4 c=1000
Clock
3 working Fast pull-in, locked, holdover and free-run.
mode
Input jitter
4 See Figure 7-1.
tolerance
Note:
z Lowest accuracy is the maximum value of the offset to the nominal frequency in a
long term (20 years) in the case of no external reference frequency (free-run mode).
z Maximum frequency offset is the maximum value of the relative frequency offset in a
unit period during the consecutive running of the clock.
z Pull-in range is the maximum frequency bandwidth of the input clock signals that the
clock can lock.
z MRTIE refers to the maximum peak-peak delay change of the tested clock to an
actual reference clock during the test.
7-2
Y(U I) P e a k-p ea k jitte r a n d wa n de r am p litu d e (lo g s ca le )
1 02
A 0 =3 6 .9
1 01
W ith the s lope ratio of 20dB/10 oc tav es
A 1 =1 .5
1
A 2 =0 .2
1 0-1
X
1 .2´1 0-5 1 0 20 2.4 k 1 8k 1 0 0k f (H z)
Figure 7-1 Maximum allowed input jitter and lower limit of wander
For example, if the jitter frequency of an input signal is 1 kHz, and the amplitude is
greater than 1.5 UI, and the system can still work normally, it indicates that the signal
meets the requirements.
Note:
UI is the unit interval. The reciprocal of the frequency of the digital signal is one UE. For
example, the UI of 2.048-Mbit/s signal is 488 ns.
7.2 Overall Structure of Clock System

Figure 7-2 shows the overall structure of the SoftX3000 clock system.
7-3
BITS 2MHz or 2MBit/s

E 8kHz E
8kHz 8kHz P P
I H.110 bus I
E H.110 bus C Clock
E1 I I
P K cable
I 2MHz I Expansion
I I frame 1
8kHz E E
8kHz
S P P
M Clock H.110 bus
I I
Serial port U Serial port cable
I I
bus I bus
Basic frame Expansion frame n
Network cable
LAN
BAM WS
Figure 7-2 Architecture of the clock synchronization system
Note:
The local area network (LAN) is connected to the HSCI through network cables but not
connected to the SMUI directly.
The SoftX3000 clock system can be divided into clock interface module, clock control
module and clock distribution module.
I. Clock Interface Module
The clock interface module includes the CKII board and the EPII board.
z The CKII can connect with an external BITS clock reference source to obtain 2
MHz or 2 Mbit/s clock reference source.
z Through dedicated clock cable, The CKII extracts the 2 MHz clock signal from E1
in the EPII as the reference source.
II. Clock Control Module
The clock control module contains workstation, BAM server, SMUI and serial port bus.
Through the clock control module, you can perform data configuration, maintenance
and status query to the SoftX3000 clock system.
7-4
III. Architecture of Clock Distribution Module
The clock distribution module includes the CKII, dedicated clock cable and H.110 bus.
The CKII is responsible for purifying the extracted clock, driving it as 16 channels of
differential clock signals, and sending them to the specific EPII board in each
expansion frame through dedicated clock cable. The EPII board in each expansion
frame provides 8-kHz clock signals to the other EPII boards in the frame through H.110
bus, to synchronize the clock of the whole system.
7.3 Implementation of Clock System Synchronization

There are two modes for synchronizing the clocks of the SoftX3000 and peer device.
z The SoftX3000 locks the clock of the peer device.
If the opposite device can provide a stable stratum-3 or higher clock, the EPII can
extract clock signals through E1 line, and transmit the extracted signals to the CKII
through 2-M clock line. The CKII board locks this reference clock and creates a clock
required by SoftX3000.
z The peer device locks the clock of the SoftX3000.
The CKII can export a stable stratum-2 clock, which serves as the reference clock to
synchronize lower-level devices. In this case, the reference clock of SoftX3000 is BITS
device.
I. Clock signal path when the SoftX3000 locks the clock of the peer device
Figure 7-3 shows the clock signal path when SoftX3000 locks the clock of the opposite
device.
7-5
E1
(2) (1)
C C E E
K K P P
I I I I
I I (3) I I
Basic frame
(4)
E E E E E E E E
P P P
...
P P P P P
I I I I I I I I
I I (5) I I I I (5) I I
Expansion frame 1 Expansion frame 8
Figure 7-3 Clock signal path when the SoftX3000 locks the clock of the peer device
2) The EPII is connected to the peer device through E1 or T1 line, which provides the
2 MHz clock.
3) Through two clock cables (double-layer shielding coaxial cable is adopted for
these 2 MHz clock cables, the two shielding layers are connected and the cable
connectors are 75 ohm SMB connectors), the EPII connected with E1 or T1 line is
connected to the active and standby CKIIs in the basic frame to import the 2 MHz
reference clock.
Note:
Only the EPII that is connected with E1 or T1 line can export the 2 MHz clock signals. In
the actual application, if there are four EPIIs in the basic frame, two EPIIs that are
connected with E1 or T1 lines can be used to provide four channels of 2 MHz clock
signals to the active and standby CKIIs.
4) The active and standby CKIIs provide two groups of H.110 bus clocks to the EPII
boards through H.110 bus to ensure the clock synchronization of the EPIIs in the
frame.
5) Through four 8-kbps clock cables, the active and standby CKIIs in the basic frame
can provide 8-kbps clock to the EPIIs in slots 0 and 1 of one expansion frame.
7-6
Note:
Due to the limited cabling space on the front panel of the CKII, each CKII can provide
16 clock signals only. The SoftX3000 can be configured with a maximum of nine frames
(eight expansion frames and one basic frame) of SS7 signaling interfaces.
6) The EPII in the expansion frame provides H.110 bus clock signals to the other
EPIIs in the frame through H.110 bus.
II. The Opposite Device Locks the Clock of SoftX3000
Figure 7-4 shows the clock signal path when the opposite device locks the clock of
SoftX3000.
B B
I I
T T
S S
0 1
(1) (1)
C C E E
K K P P
I I I I
I I (2) I I
Basic frame
(3) (3)
E E E E E E E E
P P P
...
P P P P P
I I I I I I I I
I I (4) I I I I (4) I I
Expansion frame 1 Expansion frame 8
Figure 7-4 Clock signal path when the peer device locks the clock of the SoftX3000
2) The external active and standby BITSs are connected to the active and standby
CKIIs in the basic frame through two clock cables (coaxial cables) to provide
reference clock for the CKIIs. The reference clock can be designated to 2 Mbit/s or
2 MHz according to the actual conditions.
7-7
3) The active and standby CKIIs provide two groups of H.110 bus clocks to the EPIIs
through H.110 bus to ensure the clock synchronization of the EPIIs in the frame.
4) Through four 8-kbps clock cables, the active and standby CKIIs in the basic frame
can provide 8-kbps clock to the EPIIs in slots 0 and 1 of one expansion frame.
5) The EPII in the expansion frame provides two groups of H.110 bus clock signals to
the other EPIIs in the frame through H.110 bus.
7-8
U-SYS SoftX3000 SoftSwitch System Appendix A Format of Final Bills
Appendix A Format of Final Bills
Key words: SoftX, bill, intelligent bill and ordinary bill

Summary: According to the definition of switch bill format, this document
adds the various criteria and bidding document requirements in NGN and
redefines NGN bill format, in which a field is used to indicate fixed or mobile
bill. The following definitions only cover the definition of fixed bill format,
excluding mobile part (the character in red indicates the differences with
switch).
A.1 Fixed IN bill

Length
Field Offset Remark
(bytes)
11: fixed network bill
net_type 1 0
22: mobile network bill
Equal to the record type in GB standard, which
occupies a byte. Refer to the national standard for
the meanings. 0x01: PSTN/ISDN/CTX call record
0x02: DBO call record (not available in China)
0x03: IN call record
0x04: ISDN/CTX record
bill_type 1 1 0x05: record generated by TAX (not available in
China)
0xF0: meter table bill
0xF1: meter table statistics bill
0xF2: trunk duration statistics bill
0xF3: free call statistics bill
0xFF: alarm bill
Used for checking whether the bill is saved
correctly, it is only a kind of checking mode, this
check_sum 1 2
field is not available in GB standard and occupies
one byte.
It is always 0,indicating a single record reserved
when intelligent bill integrates with ordinary bill,
partial_record_in therefore, it overlaps with charging record indicator
0.5 3
dicator and is different from that in GB standard. It uses
one byte together with validity flag and reserved bit,
and this indicator uses the lower 4 bits in this byte.
A-1
Length
Field Offset Remark
(bytes)
It is always 0, indicating valid; it is 1, indicating
valid_indicato 0.125 3.5 invalid, equal to the record validity indicator in GB
standard.
Spared 0.375 3.625 Spared bit
Indicating that which fields are available in bill, 0 for
this field is not available in bill, 1 for this field is
available in bill. This field is used for the realization
of ACR program in INAP operation, and is useless
to the user. This field is not
available in GB standard. Each field flag occupies a
bit, as shown below:
Caller number address indicator flag, 0 for not
indicated, 1 for indicated, the same hereafter.
caller number flag
location number address indicator flag
charging category indicator flag
charging mode indicator flag
partial record indicator flag
location number indicator flag
called number address indicator flag
called number flag
destination number address indicator flag
destination number flag
Intelligent Bill
4 4 charging number address information flag
Related Flag
charging number flag
incoming trunk indicator flag
outgoing trunk indicator flag
answering time flag
call end time flag
conversation duration flag
call charging flag
traffic type flag
release cause flag
indicator flag
call subscriber category flag
bearer capability flag
final service flag
tariff adjustment flag
premium flag
transparent charging flag
with other 4 bits reserved
A-2
Length
Field Offset Remark
(bytes)
he same as that in GB standard. Refer to GB
Record type 1 8
standard.
Used for AC operation in INAP, ranging 1-127. This

Charging Record
2 9 field is not available in GB standard and is useless
Indicator
for the user.
Charging It is the same as the category field of charging rate
2 11
Category in GB standard, ranging 1~1000.
Equal to the charging/free of charge identifier in GB
Charging Mode 1 13
standard, 0 for free of charge, 1 for charging.
The same as the partial record indicator field in GB
standard. For the bill with overlong conversation
duration, it is allowed to split the conversation into
multiple bills to record the call case, and the values
partial_record_in are as follows:
1 14
dicator 0 for single bill
1 for the first bill of this call
2 for the intermediate part bill of this call
3 for the last bill of this call
It is the same as the meanings of caller number
address nature indicator in GB standard, and is a
Caller number
repetition of address nature indicator in caller
address
1 15 number description. The actual meanings are as
information
follows: 0 for spared, 1 for subscriber number, 2 for
indicator
spared, 3 for domestic valid number , 4 for
international valid number
t includes 2 fields: calling number address nature
indicator and caller number, which is inherited from
AC operation number description. Only the address
nature and number content are useful to the user.
The specific meanings are as follows: Address
nature indicator: 7 bits, in which, 0 for spared, 1 for
subscriber number, 2 for spared, 3 for domestic
valid number , 4 for international valid number
Odd/even indicator: 1 bit, 0 for address information
is even, 1 for address information is odd mask
indicator: 2 bits, 0 for provided by the subscriber
Caller number
14 19 and not checked, 1 for provided by the user,
description
checked and passed, 2 for provided by the user,
checked to be faulty, 3 for provided by the network
Address presentation restriction indicator: 2 bits, 0
for presentation allowed and 1 for presentation
restricted Numbering plan indicator: 3 bits, 0 for
spared, 1 for ISDN number plan, 3 for data number
plan, 4 for subscriber telex number plan Caller
number incomplete indicator: 1 bit, 0 for complete
number, 1 for incomplete number Number length: 5
bits Spared: 3 bits Content of number: 11 bytes,
BCD code
A-3
Length
Field Offset Remark
(bytes)
It is the same as the called number address nature
Called number indicator in GB standard, and is a repetition of
address address nature in called number description. The
1 30
information actual meanings are as follows: 0 for spared, 1 for
indicator subscriber number, 2 for spared, 3 for domestic
valid number, 4 for international valid number
Refer to the caller number description, but mask
Called number indicator and address presentation restriction
14 31
description indicator are not contained, and the 4 bits occupied
by these 2 fields are spared bit.
It is the same as the translation number address

nature indicator in GB standard, and is a repetition
Destination
of address nature in destination number
number address
1 45 description. The actual meanings are as follows: 0
information
for spared, 1 for subscriber number, 2 for spared, 3
indicator
for domestic valid number, 4 for international valid
number
Destination
number 14 46 Refer to the called number description.
description
paid-party Equal to the charge party ID indicator in GB

1 60
indicator standard. Refer to GB standard for the meanings.
Designated
charge number The same as the charge number address nature
address 1 61 indicator. Refer to GB standard for specific
information meanings.
indicator
Designated
charging 11 62 BCD code
number
trunk_group_i
2 73 It is the same as the incoming trunk group identifier.
n
trunk_group_
2 75 It is the same as the outgoing trunk group identifier.
out
Equal to the answering time and time field in GB
standard,
but not to the accuracy of 100mm. It is in the
YYMMDDHHMMSS format, these 6 bytes record
ans_time 6 77
year,
month, day, hour, minute, second in the character
form in
order.
A-4
Length
Field Offset Remark
(bytes)
Equal to the conversation end time and time field in
Conversation GB standard, but not to the accuracy of 100mm. It
6 83 is in the YYMMDDHHMMSS format, these 6 bytes
end time record year,month, day, hour, minute, second in the
character form in order.
4-byte BCD code, with the format as HHHMMSST,

in which
the meanings are as follows:
conversation_
4 89 HHH: 0-255 (hour(s))
time
MM : 0-59 (minute(s))
SS : 0-59 (second(s))
T : 0-9 (100 mm)
Conversation
4 93 The same as international charge field.
charge
The same as the traffic type field in GB standard. At

present,
Traffic type 0.5 97 only local call, national originated call and
international
originated call are used. Refer to GB standard.
Equal to the conversation end cause in GB
standard. At
Release
0.5 97.5 present, only caller onhook, called onhook and
cause abnormal
end are used. Refer to GB standard.
caller_categor
1.5 98 The same as that in GB standard.
y
Identifier 0.5 99.5 This field is invalid and will not be used.
It includes selection type and selection value. The
meanings
are as follows:
Selection type occupies one byte, and is not
Bearer available in GB
3 100
capability standard, and is useless to the subscriber.
Selection value is equal to the bearer service in GB
standard, and is fixed at 1 and in character form.
Refer to
GB standard for it.
A-5
Length
Field Offset Remark
(bytes)
Equal to the teleservice in GB standard. The value
is fixed at 1, refer to GB standard for it. If no other
location fields are
Service type 0.5 103 added, actually only one byte will be occupied.
Service type occupies 4 bits and uses the lower 4
bits in the
byte, and 4 bits are spared.
Spared 0.5
Equal to the charge adjustment coefficient in GB
standard. The structure in character form is shown
Tariff 4 104 as follows: Charge adjustment ratio: occupies 2
bytes Charge adjustment type: occupies 2 bytes,
refer to GB standard for the meanings.
Equal to IN premium in GB standard, but only
Premium 4 108 premium value is included, excluding premium
type.
Transparent
transmission 20 112
charge parameter
RxFlux 4 132
TxFlux 4 136
Caller side media
gateway/ terminal 4 140
IP address
Caller side media

gateway/ terminal 4 144
IP address
Caller side soft

switch equipment 4 148
IP address
Called side soft
switch equipment 4 152
IP address
A-6
A.2 Fixed Ordinary Detail Bill Format

Length
Field (Offset) Remark
(Bytes)
11: fixed network bill
net_type 1 0
22: mobile network bill
Equal to the record type in GB standard, which
occupies a byte, refer to GB for the meanings.
0x01: PSTN/ISDN/CTX call record
0x02: DBO call record (not available in China)
0x03: IN call record
0x04: ISDN/CTX record
bill_type 1 1 0x05: record generated by TAX (not available in
China)
0xF2: trunk duration statistics bill
0xF3: free call statistics bill
0xFF: alarm bill
correctly, it is only a kind of checking mode, this
check_sum 1 2
field is not available in GB standard and
occupies one byte.
Indicating that this bill is a single record, and is

also a record of a certain time segment in a long
bill, the values are:
partial_record_indi 0: single record
0.5 3
cator
1: the first part of record
2: the intermediate part of record
3: the last part of record

valid_indicator 0.125 3.5 invalid, equal to the record validity indicator in
GB standard.
Indicating that whether the clock is modified
during the call process (such as whether the
clock_indicator 0.125 3.625
host time has been modified via BAM) 0 for
YES, 1 for NO.
0 for free of charge; 1 for charging (at present

free_indicato 0.125 3.75
the default is free call attempt)
call_attempt_indic
0.125 3.875 0 for free call attempt; 1 for charged call attempt
ator
complain_indicator 0.125 4 0 for no complaint; 1 for complaint
A-7
Length
(Bytes)
0 for non-centralized charging; 1 for centralized
cama_indicator 0.125 4.125
charging
iis_credit_indicator 0.125 4.25 0 for non-credit call; 1 for credit call

spared 0.125 4.375 spared bit
0: free of charge
1: charging the calling party
2: charging the called party
3:charging the destination address number
(used in IN)
4:third party charged, which can be divided into
case 11, 12, 13 and 14
charge_party_indi 9: charging incoming trunk
0.5 4.5
cator
10:charging outgoing trunk
11:charging calling party (third party charged)
12:charging called party (third party charged)
13:charging incoming trunk (third party
charged)
14:charging outgoing trunk (third party charged)
15:no charging
Indicating the start time of answering, the
format is:
YYMMDDHHMMSS YY:00-99(binary
MM: 1-12 (binary)
ans_time 6 5
DD: 1-31 (binary)
HH:0-23 (binary)
MM: 0-59 (binary)
SS: 0-59 (binary)
Indicating the time of conversation end, the
format is:
YYMMDDHHMMSS
YY:00-99 (binary)
end_time 6 11 MM: 1-12 (binary)
DD: 1-31 (binary)
HH:0-23 (binary)
MM: 0-59 (binary)
SS: 0-59 (binary)
the duration of this conversation recorded by
conversation_time 4 17
switch, expressed with long integer
caller_dnset 1 21 Caller number network identifier
A-8
Length
(Bytes)
the caller number address nature:
0 subscriber number caller number = local
caller_address_na number
ture Caller number 1 spared
1 22
address nature 2 domestic valid number, caller number = toll
indicator area code + local number
3 international number, caller number =country
code + toll area code + local number
Caller number, expressed with compressed
caller_number 10 23 BCD code, and the surplus bits are filled with
“0xF”
called_dnset 1 33 Called subscriber network identifier

Called address nature:
0 subscriber number called number = local
number
1 spared
called_address_na
1 34 2 domestic valid number, called number =toll
ture
area code + local
number
3 international number, called number =country
code + toll area code + local number
Called number, indicating the called number
occurred at network side, compressed with
called_number 10 35
compressed BCD code, and the surplus bits are
filled with “0xF”.
Indicating Centrex group number of charging
centrex_group_nu object, ranging 0-65535, in the case of
2 45
mber non-Centrex group subscriber, the value is
0Xffff.
Indicating the short number of caller within the

Centrex group, expressed with BCD code, if this
caller_ctx_number 5 47
field is not available, each bit should be filled
with “0xF”.
Indicating the short number of called party
called_ctx_n within the Centrex group, expressed with BCD
5 52
umber code, if this field is not available, each bit should
be filled with “0xF”.
trunk_group The group number of incoming trunk, ranging

2 57 0-65535, if this call is not via incoming trunk,
_in then it is expressed with 0xFFFF.
The group number of outgoing trunk, ranging
trunk_group_out 2 59 0-65535, if this call is not via outgoing trunk,
then it is expressed with OxFFFF
A-9
Length
(Bytes)
caller_did 1 61 Equipment type of the calling party in local office
Equipment type of the called party in local
called_did 1 62
office, ranging 0-255
Values:
00: unknown caller category
01: operator in French
02: operator in English
03: operator in German
04: operator in Russian
05: operator in Spanish
06: operator, the language adopted after the
negotiation of both parties (Chinese)
negotiation of both parties
negotiation of both parties (Japanese)
09: domestic operator
0A: ordinary subscriber (toll-toll, toll– local)
0B: priority subscriber (toll-toll, toll-local,
caller_category 1 63 local-local)
0C: data call (speech band data)
0D: test call
0E: spared
0F: collect call
10 — BF: spared
E0 — EF: national spared
F0: ordinary FPH (local-toll)
F1: ordinary periodic subscriber (local-toll)
F2: ordinary immediate subscriber table
(local-toll)
F3: ordinary immediate printer (local-toll)
F4: prior FPH (local-toll)
F5: prior periodic subscriber (local-toll)
F8: ordinary local subscriber (local-local, used
by the local office)
Values:
1. intra-office
2: incoming office
call_type 0.5 64
3. outgoing office
4: tandem
5: new service
A-10
Length
(Bytes)
Values:
0: local office
1: local
2: local toll
gsvn 0.5 64.5
3: national toll
4: international toll
5: new service
14: local CENTREX
termination_code 1 65 failure cause code
spared1 0.5 66
0: caller off-hook;
terminating_reaso
0.5 66.5 1: called off-hook;
n
2: abnormal end
Description of the supplementary services
Calling SS during called during the call
7 67
the call Note: The explanation of this field is not defined
in GB standard, use 0 temporarily.
The charging case value of this call, determined

charging_case 2 74 by the host
charging setup data
rate 2 76 Charging unit price. The unit: minute
Receiving the number of charging pulse from

pulse_count 4 78
the senior office
4 82 The fee (including premium) calculated
fee 4 82 according to the host charging data. The unit:
minute
connected_dnset 1 86 Connected number network identifier
Connected number address nature
0: subscriber number, connected number =
local number
connected_addres 1. spared
1 87
s_nature 2: national valid number, connected number =
toll area code + local number
3: international number, connected number =
country code+ toll area code + local number
The connected number refers to the actual
connection number of this call, mainly
connected_numbe displaying the information, expressed in
10 88
r compressed BCD code, and the surplus bits are
filled by “0xF”. In normal cases, the connected
number is equal to the called number, and the
A-11
Length
(Bytes)
exceptional case is: call transfer of the called
subscriber, the connected number is the actual
connection number after the transfer.
charge_dnset 1 98 Charge number network identifier

The values indicating the charging number
address nature:
0: subscriber number, charging number = local
number
1: spared
2: national valid number, charging number = toll
area code + local number
3: international number, charging number =
country code+ toll area code + local number
4: account card, A card
5: account card, B card
charge_address_n 6: account card, C card
1 99
ature 7: account card, D card
8: VISA card
9: CTX group number
10: CTX intra-group extension number
12: account of Industrial and Commercial Bank
of China
13: account of Bank of Construction
14: account of Bank of China
15: account of Communication Bank of China
16: account of Agricultural Bank of China
others: spared
Describing various kinds of subscriber number,
card number, account in the compressed BCD
charge_number 10 100
mode (including Centrex group number), the
surplus bits are filled with “0xF”.
Values:
1: circuit mode, 64Kbps unrestricted, 8KHZ
structured bearer service
2: circuit mode, 64Kbps, 8KHZ structured
bearer voice, including 100, 101, 102 and 103
bearer_service 1 110 3: circuit mode, 64Kbps, 8KHZ structured
bearer 3.1KHZ voice
4: packet mode, ISDN virtual call, permanent
virtual circuit service is accessed by the
subscriber provided by the B channel
5: subscriber signaling bearer service
7: circuit mode, 2X64Kbps unrestricted, 8KHZ
A-12
Length
(Bytes)
structured bearer service type
10: circuit mode, 30X64Kbps unrestricted,
8KHZ structured bearer service type
100: voice, analog subscriber calls analog
subscriber
101: voice, analog subscriber calls digit
subscriber
102: voice, digit subscriber calls analog
subscriber
103: voice, digit subscriber calls digit subscriber
255: unknown
Others: spared
Values:
0: spared
1: 3.1K telecom service
2: 7Khz telecom service
3: category-4 fax
4: intelligent subscriber telegraph
5: videotex
6: mixed telecom service
7: 7Khz image
10: 5.3Khz voice
11: 6.3Khz voice
12: 8Khz voice
13: 16Khz voice
teleservice 1 111
14: 24Khz voice
15: 32Khz voice
16: 48Khz voice
17: 56Khz voice
18: 64Khz voice
30: 64Khz*1 image
31: 64Khz*2 image
32: 64Khz*3 image
33: 64Khz*4 image
34: 64Khz*5 image
35: 64Khz*6 image
36: 64Khz*7 image
37: 64Khz*8 image
A-13
Length
(Bytes)
38: 64Khz*9 image
39: 64Khz*10 image
40: 64Khz*11 image
41: 64Khz*12 image
42: 64Khz*13 image
43: 64Khz*14 image
44: 64Khz*15 image
45: 64Khz*16 image
46: 64Khz*17 image
47: 64Khz*18 image
48: 64Khz*19 image
49: 64Khz*20 image
50: 64Khz*21 image
51: 64Khz*22 image
52: 64Khz*23 image
53: 64Khz*24 image
54: 64Khz*25 image
55: 64Khz*26 image
56: 64Khz*27 image
57: 64Khz*28 image
58: 64Khz*29 image
59: 64Khz*30 image
255 Unknown
Others: spared
RxFlux 4 112 How many bytes have been received?

TxFlux 4 116 How many bytes have been sent?
CliGK 4 120
CliGW 4 124
CldGK 4 128 If it cannot be obtained, omit it.
CldGW 4 132
ITUT codec definition below
0: no indication
1: G.711 64 kbit/s A-law
2: G.711 64 kbit/s m-law
CodeType 1 136
3: G.711 56 kbit/s A-law
4: G.711 56 kbit/s m-law
5: G.722 (SB-ADPCM)
6: G.723.1
A-14
Length
(Bytes)
7: G.723.1 Annex A (silence suppression)
8: G.726 (ADPCM)
9: G.727 (Embedded ADPCM)
10: G.728
11: G.729 (CS-ACELP)
12: G.729 Annex B (silence suppression)
13: G.722
14: G.722.1
60: H.261
61: H.263
62: H.262
63: MPEG1
64: MPEG2
65: MPEG4
66: MPEG7
67: MPEG21
ETSI(3GPP) codec definition below
100: GSM Full Rate (13.0 kbit/s)

101: GSM Half Rate (5.6 kbit/s)
102: GSM Enhanced Full Rate (12.2 kbit/s)
103: Full Rate Adaptive Multi-Rate
104: Half Rate Adaptive Multi-Rate
105: UMTS Adaptive Multi-Rate
106: UMTS Adaptive Multi-Rate 2
107: TDMA Enhanced Full Rate (7.4 kbit/s)
108: Enhanced Full Rate (6.7 kbit/s)
IETF definition below
150: 1016
151: clock rate: 8000
152: clock rate: 16000
154: L16 2 channels
155: L16 1 channel
158: DVI4, clock rate: 11025
159: DVI4, clock rate: 22050
UUS1 count 1 137 Number of switched UUS1 segments (64 bytes/
A-15
Length
(Bytes)
segment)
Number of switched UUS2 segments (64 bytes/
UUS2 count 1 138
segment)
Number of switched UUS3 segments (64 bytes/
UUS3 count 1 139
segment)
A.3 Fixed Network Meter Table Bill Format

Length
Field Offset Remark
(byte)
Csn 4 0 Sequence of CDR
It is equal to the record type in GB standard,
occupying one byte. Refer to GB standard for
the meaning.
0x01: call records of PSTN/ISDN/CTX
0x02: call records of DBO (not provided
domestically)
0x03: call records of IN
bill_type 1 4 0x04: records of ISDN/CTX
0x05: records generated by TAX (not provided
domestically)
0xF2: trunk occupation duration statistics bill
0xF3: statistics bill of free calls
0xFF: alarm bill

correctly. It is only a kind of check method, not
check_sum 1 5
provided in the GB standard, occupying one
byte.
Indicating whether the bill is an independent

record or it is a time segment record in the long
partial_record_indi 0: single record
0.5 6
cator
1: the first part of the record
2: the middle part of the record
3: the last part of the record

GB standard.
A-16
Length
Field Offset Remark
(byte)
0: subscriber 1: incoming trunk 2: outgoing
Charge object 0.25 6.625
trunk
Spared 0.125 6.875
Number of meter The number of the meter tables. It is currently
1 7
tables 20.
Indicating the date and time when the meter
table is generated, the format is:
YYMMDDHHMMSS
YY:00-99 (binary)
Date and time of
meter table 6 8 MM: 1-12(binary)
generation DD: 1-31(binary)
HH:0-23 (binary)
MM: 0-59 (binary)
SS: 0-59 (binary)
Dnset 1 14 Number network identifier

Number address nature:
0: subscriber number, number = local number
1: spared
address_nature 1 15 2: national valid number, number = toll area
code + local number
3: international number, number = country code
+ toll area code + local number
The subscriber number, expressed in
Number 10 16 compressed BCD code, and the surplus bits
are filled with “0xF”.
The charge objects are the trunk number and
Trunk group
2 26 the trunk group number in the case of the
number
outgoing trunk.
The number of the module that the subscriber

Module number 1 28
or the trunk group belongs to
Subscriber The equipment type of the subscriber meter

1 29
equipment type table: value range (0-255)
The equipment sequence of the subscriber

Equipment
2 30 within the module 0-65534, 65535 is a void
sequence number
value
Value of meter The value accumulated on the table since the
2 32
table 1 last meter table bill is generated
Call times of meter The call number accumulated on the table
2 34
table 1 since the last meter table bill is generated
2 36
A-17
Length
Field Offset Remark
(byte)
2 38

2 40

2 42

2 44

2 46

2 48

2 50

2 52

2 54

2 56

2 58

2 60

2 62

2 64

2 66

2 68

2 70

2 72

2 74

2 76
A-18
Length
Field Offset Remark
(byte)
2 78

2 80
table 13 last meter. table bill is generated

2 82

2 84

2 86

2 88

2 90

2 92

2 94

2 96

2 98

2 100

2 102

2 104

2 106

2 108

2 110
reserved 6 112
A-19
A.4 Fixed Network Meter Table Statistics Bill

(statisticsMeterBill)
Length
Field Offset Remark
(byte)
net_type 1 0 11: fixed network bill 22: mobile network bill
the meaning.
domestically)
domestically)
0xFF: alarm bill

check_sum 1 2
byte.
Indicating whether the bill is an independent

record or it is a time segment record in the long
partial_record_ind 0: single record
0.5 3
icator
1: the first part of the record
2: the middle part of the record
3: the last part of the record

GB standard.
Spared 0.375 3.625

Number of meter The number of the meter tables. It is currently
1 4
tables 20.
A-20
Length
Field Offset Remark
(byte)
YYMMDDHHMMSS
YY:00-99 (binary)
Date and time of MM: 1-12 (binary)
6 5
bill generation
DD: 1-31 (binary)
HH:0-23 (binary)
MM: 0-59 (binary)
SS: 0-59 (binary)
The number of the module generating the meter
Module number 1 11
table statistics bills, with the value range: 1-240
The call type. The values:

1: local office statistics
2: incoming office statistics
3: outgoing office statistics
Call type 1 12
4: tandem statistics
Others: invalid
Note: It indicates the statistics type of this meter
table bill.

2 13
table 1 last meter table bill is generated (same below)
The call number accumulated on the table since
Call times of meter
2 15 the last meter table bill is generated (same
table 1
below)
Value of meter
2 17
table 2
Call times of meter
2 19
table 2
Value of meter
2 21
table 3
Call times of meter
2 23
table 3
There are totally 20 meter tables, and the detailed description will be omitted.
A-21
A.5 Fixed Network Trunk Occupation Duration Statistics Bill

Length
Field Offset Remark
(byte)
the meaning.
domestically)
domestically)
0xFF: alarm bill

check_sum 1 2
byte.
Spared 0.5 3
invalid, equal to the record validity indicator in
valid_indicator 0.125 3.5
GB
standard.
Spared 1.375 3.625

Indicating the date and time when the trunk
generation occupation duration statistics bill is
generated, the format is: YYMMDDHHMMSS
YY:00-99 (binary)
Date and time of MM: 1-12 (binary)
6 5
bill
DD: 1-31 (binary)
HH:0-23 (binary)
MM: 0-59 (binary)
SS: 0-59 (binary)
The number of the module generating the trunk

occupation duration statistics bills, with the
Module number 1 11
value
range of 1-240
A-22
Length
Field Offset Remark
(byte)
Spared 1 12
The charge objects are the trunk number and
Trunk group
2 13 the trunk group number in the case of the
number
outgoing trunk.
Incoming
The conversation duration is calculated in the
conversation 4 15
unit of seconds.
duration
Incoming call times 2 19

Tandem
conversation 4 21
duration
Tandem call times 2 25

Outgoing
conversation 4 27
duration
Outgoing call times 2 31
A.6 Fixed Network Statistics Bill of Free Calls

Length
Field Offset Remark
(byte)
the meaning.
domestically)
domestically)
0xFF: alarm bill
A-23
Length
Field Offset Remark
(byte)
check_sum 1 2
byte.
Spared 0.5 3

GB standard.
Spared 1.375 3.625

table
is generated, the format is: YYMMDDHHMMSS
Date and time of YY:00-99 (binary)
bill 6 5 MM: 1-12 (binary)
generation DD: 1-31(binary)
HH:0-23 (binary)
MM: 0-59 (binary)
SS: 0-59 (binary)
The number of the module generating the meter

Module number 1 11 table statistics bills, with the value range of
1-240
Spared 1 12
Statistics value of The statistics value of free call duration since
4 13
free call duration the last free call statistics bill is generated
Statistics value of The statistics value of free call times since the
2 17
free call times last free call statistics bill is generated
A-24
A.7 Supplementary Service Bill

Length
Field Offset Remark
(byte)
the meaning.
domestically)
domestically)
0xFF: alarm bill

check_sum 1 2
byte.
Spared 0.5 3
GB standard.
Spared 1.375 3.625

YYMMDDHHMMSS
YY:00-99 binary
Service ending MM: 1-12 binary
3 5
date and time
DD: 1-31 binary
HH:0-23 binary
MM: 0-59 binary
SS: 0-59 binary
A-25
Length
Field Offset Remark
(byte)
Service type:
0X02 CFU
0X03 CFB
Service type 1 11
0X04 CFNA
0X20 Centrex
ICW
The caller number, expressed in compressed

Caller number 10 12 BCD code, and the surplus bits are filled with
“0xF”.
The charged party number, expressed in
Charged party compressed
10 22
number indication BCD code, and the surplus bits are filled by
“0xF”
The numbers triggering the services(BCD code)

Service initiating CF: The number dialed by the caller
10 32
party number Centrex: The caller number
ICW: The called number
The service ending numbers:

CF: The forwarded number
Service accepting
10 42 Centrex: The actual number of the called party
party number
ICW: The receiving/forwarding number
designated by the subscriber
Service triggered
1 52 Times of service triggered
times
Ending cause 2 53 The ending cause code

Service starting
6 55 The service starting time
date and time
Paying method:
1: charging by month
Paying method 1 61
2: charging by quarter
3: charging by usage times
Service fee 4 62 The service fee

Conversation
4 66 The conversation duration
duration
A-26
U-SYS SoftX3000 SoftSwitch System Appendix B Acronyms and Abbreviations
Appendix B Acronyms and Abbreviations
Abbreviation Full name

A
ALUI Alarm Unit
ARQ Admission Request
B
BAM Back Administration Module
BFII Back insert FE Interface Unit
BITS Building Integrated Timing Supply
BRQ Bandwidth Request
BSGI Broadband Signaling Gateway
BHCA Busy Hour Call Attempt
C
CDBI Central Database Board
CIC Circuit Identification Code
CKII Clock Interface Unit
CPU Central Processing Unit
CRC Cyclic Redundancy Check
D
DDN Digital Data Network
Distributed Object-Oriented Programmable Real-Time
DOPRA
Architecture
DPC Destination Point Code
DRQ Disengage Request
DSS1 Digital Subscriber Signaling No.1
E
EPII E1_Pool Interface Unit
F
FCCU Fixed Calling Control Unit
FCSU Fixed Calling Control Unit and signaling process Unit
FTAM File Transfer Access and Management Protocol
B-1

FTP File Transfer Protocol
G
GUI Graphical User Interface
H
H.248 H.248/MeGaCo protocol
HSCI Hot-Swap and Control Unit
HTTP Hyper Text Transport Protocol
I
IFMI IP Forward Module
iGWB iGateWay Bill
INAP Intelligent Network Application Part
IRQ Information Request
Integrated Services Digital Network User Part/ISDN
ISUP
User Part
IUA ISDN User Adaptation Layer
K
KVM Keyboard/Video/Mouse
L
LCD Liquid Crystal Display
M
M2UA SS7 MTP2-User Adaptation Layer
M3UA SS7 MTP3-User Adaptation Layer
MAC Media Access Control
MG Media Gateway
MGCP Media Gateway Control Protocol
MML Man-Machine Language
MRCA Media Resource Control Unit
MRIA Media Resource Interface Unit
MRS Media Resource Server
MSGI Multimedia Signaling Gateway Unit
MTP1 SS7 Message Transfer Part Level 1
B-2

N
NI Network Indicator
O
OPC Originating Point Code
HUAWEI Open Standards Telecom Architecture
OSTA
Platform
P
PCM Pulse Code Modulation
PCI Peripheral Component Interconnect
POTS Plain Old Telephone Service
PSTN Public Switched Telephone Network
R
RAS Registration, Admission and Status
RRQ Registration Request
S
SCTP Stream Control Transmission Protocol
SI Service Indicator
SIP Session Initiated Protocol
SIUI System Interface Unit
SQL Structured Query Language
SMUI System Management Unit
SNMP Simple Network Management Protocol
SS7 Signaling System No. 7
SSM Synchronization Status Message
T
TCP Transmission Control Protocol
TDM Time Division Multiplex
U
UDP User Datagram Protocol
UPWR Universal Power
URQ Unregistration Request
V
V5UA V5 User Adaptation Layer
B-3

W
WS WorkStation
B-4
U-SYS SoftX3000 SoftSwitch System Index
Index
A D
alarem box, 5-3 data format conversion, 3-20
alarem levels, 5-3 data setting, 3-20
alarm categories, 5-2 data storage
alarm console, 5-4 BAM data, 3-14
alarm generation sytem, 5-2 host data, 3-14
alarm path for media resource frame, 5-6 supplementary service data, 3-15
alarm path for power distribution frame, 5-8 detailed bill, 4-2
alarm path for service processing frame, 5-5 DSS1 signaling processing path, 2-18
architecture of charging system, 4-4
E
B
emergency workstation, 3-2
BAM, 1-2, 3-1 Ethernet dual planes, 1-8
BAM software program, 3-6
bill pool, 4-4 F
bill storage directory, 4-9
fault detection system, 5-1
billing center, 4-5
feature of BAM
bottom-layer signaling processing module
client/server structure, 3-7
BSGI, 1-5
high reliablilty, 3-7
FCSU, 1-5
final bile file name, 4-12
MSGI, 1-5
fixed IN bill format, A-1
bus
fixed network trunk occupation duration statistics bill
ethernet bus, 1-7
format, A-22
H.110 bus, 1-9
fixed ordinary detail bill format, A-7
serial port bus, 1-11
format of final bill file, 4-12
shared resource bus, 1-6
free call statistics bill format, A-23
C G
Centrex bill charging path, 4-7
GUI, 3-9
charging path, 4-5
clock signal path when be locked by peer device, 7-7
H
clock signal path when locks peer device, 7-5
H.323 signaling processing path
communication gateway software, 3-11
H.323 CALL, 2-11
CRC check, 3-21
RAS, 2-11
hardware architecture
environment monitoring subsystem, 1-3
i-1
maintenance management subsystem, 1-2 P

service processing subsystem, 1-1
patch number, 3-22
hardware composition, 1-1
patch state transition, 3-25
power introduction module, 6-1
I
iGWB, 1-2, 3-2 S
iGWB processing path, 4-7
security manage
interface module
account management, 3-14
BFII, 1-4
locking the client, 3-14
CKII, 1-4
specifying login time, 3-14
EPII, 1-4
workstation management, 3-13
IFMI, 1-4
security management
IP address of boards, 3-18
command group, 3-13
iWeb, 3-7
service processing module
CDBI, 1-5
L
FCCU, 1-5
loading path, 3-16 SIP signaling processing path, 2-15
logical architecture, 1-3 software alarm reporting path, 5-8
software architecture of terminal system, 3-2
M statistical bill, 4-3
M2UA signaling processing path, 2-3 statistics meter bill format, A-20
M3UA signaling processing path, 2-5 statum-2 clock, 7-1
meter table bill format, A-16 statum-3 clock, 7-1
metering bill, 4-3 storage of final bills, 4-11
MGCP/H.248 signaling processing path, 2-7 storage of original bills, 4-9
MML, 3-9 structure of clock system, 7-3
monitoring environment principle, 6-6 supplementary service bill format, A-25
monitoring fan principle, 6-6 system support module
monitoring PDF principle, 6-4 HSCI, 1-4
monitoring power supply principle, 6-5 SIUI, 1-4
SMUI, 1-4
N
networking of terminal system, 3-1 T
NMS, 3-3 TDM signaling path, 2-1
number and use of cables on PDF, 6-3 technical specifications of clock sytem, 7-1
types of final bill, 4-10
O
offline billing, 4-1 U
online billing, 4-1 use of power controlling switches, 6-3
operation and maintenance module, 1-5
OSTA frames, 1-1
i-2
V W
V5UA signaling processing path, 2-20 workstation, 3-2
version specific, 3-22
i.
i-3

SoftX3000 Technical Manual-System Principle

Uploaded by

Copyright:

Available Formats

You might also like

SoftX3000 Technical Manual-System Principle

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SoftX3000 Technical Manual-System Principle

Uploaded by

Copyright:

Available Formats

Chapter 1 System Architecture ......................................................................

U-SYS SoftX3000 SoftSwitch System

Huawei Technologies Proprietary

Volume System Principle

Manual Version T2-010259-20050608-C-3.32

Product Version V300R003

Huawei Technologies Co., Ltd.

Address: Administration Building, Huawei Technologies Co., Ltd.,

Bantian, Longgang District, Shenzhen, P. R. China

Postal Code: 518129

Huawei Technologies Proprietary

All Rights Reserved

No part of this manual may be reproduced or transmitted in any form or by any

, HUAWEI, C&C08, EAST8000, HONET, , ViewPoint, INtess, ETS, DMC,

Huawei Technologies Proprietary

The manual applies to U-SYS SoftX3000 SoftSwitch System V300R003 (hereinafter

The related manuals are listed in the following table.

It details on the hardware architecture,

It covers the detailed procedure of installing the

U-SYS SoftX3000 SoftSwitch It guides the maintenance engineers to perform

Huawei Technologies Proprietary

It guides the engineers how to configure various

It guides the engineers how to use the GUI on

It elaborates on the functioning principle of the

There are seven chapters and two appendixes in the manual.

Huawei Technologies Proprietary

The manual is intended for the following readers:

The manual uses the following conventions:

Huawei Technologies Proprietary

Note: Means a complementary description.

Huawei Technologies Proprietary

Chapter 1 System Architecture.................................................................................................... 1-1

Chapter 2 Processing Path for Signaling ................................................................................... 2-1

Huawei Technologies Proprietary

2.7.1 Uplink Path ............................................................................................................ 2-18

Chapter 3 Operation and Maintenance Principle ....................................................................... 3-1

Chapter 4 Charging System ......................................................................................................... 4-1

Huawei Technologies Proprietary

4.3.1 Bill Storage Directory .............................................................................................. 4-9

Chapter 5 Alarm System............................................................................................................... 5-1

Chapter 6 Environment Monitoring System ............................................................................... 6-1

Chapter 7 Clock Synchronization System .................................................................................. 7-1

Appendix A Format of Final Bills.................................................................................................A-1

Huawei Technologies Proprietary

Appendix B Acronyms and Abbreviations .................................................................................B-1

Index ................................................................................................................................................ i-1

Huawei Technologies Proprietary

Chapter 1 System Architecture

1.1 Hardware Composition

FE: Fast Ethernet interface 3×FE: Three FE cables WS: Workstation

The SoftX3000 hardware architecture is composed of three subsystems:

1.1.2 Service Processing Subsystem

Huawei Technologies Proprietary

The communication of the SoftX3000 service processing subsystem involves the

II. System Capacity Feature

1.1.3 Maintenance Management Subsystem

The maintenance management subsystem, or background, is composed of the

Huawei Technologies Proprietary

network management interface is provided to external devices through this LAN