2.8.2 downlink path 2-21 -...

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

1.1 Hardware Composition 1-1...........................................................................1.1.1 Service Processing Subsystem 1-1.....................................................1.1.2 Maintenance Management Subsystem 1-2..........................................1.1.3 Environment Monitoring Subsystem 1-3..............................................

1.2 Logical Architecture 1-3................................................................................1.2.1 Interface Module 1-4............................................................................1.2.2 System Support Module 1-4.................................................................1.2.3 Bottom-Layer Signaling Processing Module 1-5..................................1.2.4 Service Processing Module 1-5...........................................................1.2.5 Operation and Maintenance Module 1-5..............................................

1.3 Buses 1-6.....................................................................................................1.3.1 Shared Resource Bus 1-6....................................................................1.3.2 Ethernet Bus 1-7..................................................................................1.3.3 H.110 bus 1-9.......................................................................................1.3.4 Serial Port Bus 1-11...............................................................................

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

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 Technologies Proprietary

HUAWEI

U-SYS SoftX3000 SoftSwitch System Technical Manual – System Principle

V300R003


U-SYS SoftX3000 SoftSwitch System

Technical Manual

Volume System Principle

Manual Version T2-010259-20050331-C-3.30

Product Version V300R002

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: [email protected]


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 System Technical Manual-System Description

It provides an overall introduction to the SoftX3000, including product features, applications, and technical specifications.

U-SYS SoftX3000 SoftSwitch System Technical Manual-System Principle

It details on the hardware architecture, component interworking mechanism, and subsystems of alarm, billing, and clock in the SoftX3000.

U-SYS SoftX3000 SoftSwitch System Hardware Description Manual

It details the features and technical specifications of the hardware components of the SoftX3000, including cabinets, frames, boards, cables, and cabinet internal components.

U-SYS SoftX3000 SoftSwitch System Technical Manual–Services and Features

It covers various services and functions supported by the SoftX3000, including voice services, supplementary services, IP Centrex services, multi-media services, value added services, dual homing functions, charging functions, IPTN functions, remote network access functions, and so on.

U-SYS SoftX3000 SoftSwitch System Hardware Installation Manual

It details the installation procedure of the SoftX3000 hardware components, and matters needing attention during the installation process.

U-SYS SoftX3000 SoftSwitch System Software Installation Manual

It covers the detailed procedure of installing the SoftX3000 software, including BAM server, emergency workstation, and client, focusing on the key points that might cause installation failure.

U-SYS SoftX3000 SoftSwitch System Routine Maintenance Guide

It guides the maintenance engineers to perform daily maintenance, monthly maintenance, and yearly maintenance tasks on the SoftX3000.


Manual Content

U-SYS SoftX3000 SoftSwitch System Emergency Maintenance Manual

It guides the maintenance engineers to perform recovery operations in the case of emergencies, such as congestion of global service, AMG, and TMG, and failure of host and BAM.

U-SYS SoftX3000 SoftSwitch System Part Replacement Guide

It guides the maintenance engineers on how to replace hardware components of the SoftX3000, such as boards, fan frame, LAN Switch, and hard disk.

U-SYS SoftX3000 SoftSwitch System Operation Manual-Configuration Guide

It guides the engineers how to configure various data in the SoftX3000, including configuration steps, preparations, database table referencing relationships, and command parameters.

U-SYS SoftX3000 SoftSwitch System Operation Manual-Configuration Examples

It guides the engineers how to configure various data in the SoftX3000, including networking example, configuration script, key parameters and debugging guidance.

U-SYS SoftX3000 SoftSwitch System Operation Manual-Performance Measurement

It guides the engineers how to work on performance measurement tasks and analyze measurement results.

U-SYS SoftX3000 SoftSwitch System Operation Manual-GUI Guide

It guides the engineers how to use the GUI on various clients of the SoftX3000, including operations on menus and navigation tree. In addition, it introduces the operations on TableBrowse.

U-SYS SoftX3000 SoftSwitch System BAM User Manual

It guides the engineers how to install and use the software related to the BAM, including remote maintenance software, anti-virus software, system customized software, and so on.

U-SYS iGateway Bill User Manual

It elaborates on the functioning principle of the iGateway Bill. Also, it teaches you on how to install, maintain, and operate the product.

Organization

This manual introduces the hardware architecture, component interworking mechanism, and subsystems of alarm, billing, and clock in SoftX3000.

There are ten chapters in the manual.

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

Chapter 2 Processing Path for Signaling details processing path of TDM and IP based signaling in the SoftX3000.


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.

Chapter 4 Charging System focuses on the charging and billing process and mechanism in SoftX3000.

Chapter 5 Alarm System details on alarm system architecture, the functions and features of alarm box and alarm console, and alarm reporting path.

Chapter 6 Environment Monitoring System details the monitoring principle and process of power supply system, fan, and the equipment room.

Chapter 7 Clock Synchronization System provides more information about the features, specifications, and synchronization principle of the clock system in SoftX3000.

Appendix A Format of Original Bills lists the different formats of original bills. 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:

NGN network planning experts NGN network administrators 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.

Technical Manual – System Principle U-SYS SoftX3000 SoftSwitch System Table of Contents


i

Table of Contents

Chapter 1 System Architecture.................................................................................................... 1-1 1.1 Hardware Composition ...................................................................................................... 1-1

1.1.1 Service Processing Subsystem............................................................................... 1-1 1.1.2 Maintenance Management Subsystem................................................................... 1-2 1.1.3 Environment Monitoring Subsystem ....................................................................... 1-3

1.2 Logical Architecture ........................................................................................................... 1-3 1.2.1 Interface Module...................................................................................................... 1-4 1.2.2 System Support Module.......................................................................................... 1-4 1.2.3 Bottom-Layer Signaling Processing Module ........................................................... 1-5 1.2.4 Service Processing Module..................................................................................... 1-5 1.2.5 Operation and Maintenance Module....................................................................... 1-5

1.3 Buses ................................................................................................................................. 1-6 1.3.1 Shared Resource Bus ............................................................................................. 1-6 1.3.2 Ethernet Bus............................................................................................................ 1-7 1.3.3 H.110 bus ................................................................................................................ 1-9 1.3.4 Serial Port Bus ...................................................................................................... 1-11

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

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



ii

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



iii

4.3.2 Storage of Original Bills........................................................................................... 4-9 4.3.3 Storage of Final Bills ............................................................................................. 4-10

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 Original 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 ................................................................................................................................................ i-1

Technical Manual – System Principle U-SYS SoftX3000 SoftSwitch System Chapter 1 System Architecture


1-1

Chapter 1 System Architecture

1.1 Hardware Composition Figure 1-1 illustrates the physical composition and interconnection of the SoftX3000.

Frame 0

LAN Switch 0

LAN Switch 1BAM

Active iGWB

FE

3 x FE

FE

Host

Background

To the billingcenter

WS WS WS

LAN Switch

To NMS

FE

Emergencyworkstation

Frame 1

Frame 2

Frame 17

Standby iGWB

To the billingcenter

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—service processing subsystem, maintenance management subsystem, and environment monitoring subsystem.

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

I. Inter-Device Communication

The communication of the SoftX3000 service processing subsystem involves the following three parts:



1-2

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.

The OSTA frames communicate with exterior network devices through time-division multiplexing (TDM) or IP interfaces.

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.

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.2 Maintenance Management Subsystem

The maintenance management subsystem, or background, is composed of BAM, emergency workstation, workstation, iGWB, and connection devices. It implements functions of operation maintenance, and bill management. The communication of maintenance management subsystem involves the following four aspects:

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

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 network management interface is provided to external devices through this LAN Switch.

When communicating with the billing center, the active and standby iGWBs are connected to an Ethernet cable respectively providing FE ports to external devices.

The emergency workstation periodically backs up the data of BAM. Once the BAM becomes faulty, the emergency workstation takes the responsibility of the BAM after its Ethernet cables are connected to both LAN Switches in the planes 0 and 1 respectively.



1-3

1.1.3 Environment Monitoring Subsystem

The environment monitoring subsystem includes the power supply monitoring module, fan monitoring module (of every service processing subrack), and the 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 Architecture Figure 1-2 illustrates the SoftX3000 logical architecture.

System support module

Ethernet bus/Shared resource bus

Devicemanagement unit

MTP2processing

unitE1 interface

module Service processing unit

Broadbandsignaling

processing unit

Multimediasignaling

processing unit

Clockinterface unit

Ethernet bus/Shared resource bus

Broadbandsignaling

processing unit

FE interfaceunit

Databaseprocessing unit

Equipmentmanagement unit

E1 interfacemodule

Multimediasignaling

processing unit

MTP2processing unit Service processing unit

iGWB 1

BAM

WS WS

LANSwitch

iGWB 0


System support module

Service processing moduleSignaling processing moduleInterface module

Interface module Signaling processing module Service processing module

FE interface

BITS interface

2MHzclock

InternalPCI bus

HW

HW

E1 interface

E1 interface

InternalPCI bus

Basic frame

Expansion frame n

Operation andmaintenance module

Figure 1-2 System logical architecture

Logically, the SoftX3000 is composed of five modules—interface module, system support module, bottom-layer signaling processing module, service processing module, and operation and maintenance (OAM) module.



1-4

Note:

For detailed information about racks, cabinets, frames, boards, and cables, refer to U-SYS SoftX3000 SoftSwitch System Hardware Description Manual.

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)

The EPII implements E1/T1 framing and line interface functions, and interworks with the signaling processing module through internal highway (HW).

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

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

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.

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

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.

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.

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

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.

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.

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.

H.110 busSerial port bus

Ethernet bus B

Shared resource bus BShared resource bus A

Ethernet bus A

SIUI

SIUI

HSCI

SMUI

SMUI

ALUI

HSCI

BB

BB

BB

BB

BB

BB

BB

BB

BB

BB

BB

BB

FB

FB

FB

FB

FB

FB

FB

FB

FB

FB

FB

FB

BB: Back board

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.

Shared resource bus A

FB

SMUI

SMUI

SIUI

HSCI

SIUI

HSCI

BFII

BFII

Shared resource bus B

FB

FB

FB

FB

FB

FB

FB

FB

FB

FB

FB

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.

SMUI

Ethernet bus B

Network cables

Ethernet bus A

FB

SMUI

SIUI

SIUI

HSCI

HSCI

FB

FB

FB

FB

FB

FB

FB

FB

FB

FB

FB

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.

OSTA frame

SMUI

Internalnetwork cable

Externalnetwork cable

LAN Switch

LAN Switch

3×FE

SMUI

SIUI

SIUI

HSCI

HSCIInternal

network cable




Figure 1-6 Ethernet dual planes

Note:

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.

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.

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

Processingboard A

HSCI0

Ethernet bus

HSCI1OSTA frame A

Externalnetworkcable LAN Switch 0

LAN Switch 1

HSCI0

HSCI1 OSTA frame B

Ethernet bus



Externalnetworkcable

Ethernet bus

Ethernet busProcessing

board C

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

LAN Switch 0

Processingboard A

LAN Switch 1

HSCI0

OSTA frame A

3 x FE

Externalnetworkcable

Etnernet bus

HSCI0

HSCI1

HSCI1

OSTA frame B

Processingboard C


Etnernet bus

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:

Service changeover between active and standby FCSUs Transmission channel for reference clock signals inside the frame



1-10

H.110 bus

BB

SIUI

HW

SIUI

HSCI

HSCI

SMUI

SMUI

FB

HWHWHWHWHW HWHWHWHWHWHW

BB

BB

BB

BB

BB

BB

BB

BB

BB

BB

BB

FB

FB

FB

FB

FB

FB

FB

FB

FB

FB

FB

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

Internal HW

FCSU0

EPII

H.110 bus

EPII1

FCSU1

Internal HW

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.

Serial port bus

BB

SMUI

SMUI

SIUI

SIUI

ALUI

BB

BB

BB

BB

BB

BB

BB

BB

BB

BB

BB

Figure 1-11 Serial port bus

Technical Manual – System Principle U-SYS SoftX3000 SoftSwitch System Chapter 2 Processing Path for Signaling


2-1

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.

Ethernet bus

EPII

EPII

FCSU

FCSU

SIUI

HSCI

SIUI

HSCI

FCCU

FCCU

SMUI

SMUI

H.110 bus

Core LAN Switch Core LAN Switch

Frame A

HW

E1

FE FE

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

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.

Ethernet bus

EPII

EPII

FCSU

FCSU

SIUI

HSCI

SIUI

HSCI

FCCU

FCCU

SMUI

SMUI

H.110 bus


FrameA

HW

E1

FE FE

0

0

1

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

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.

BFII

BFII

IFMI

IFMI

FE FE

BSGI

Ethernet bus

SIUI

HSCI

SIUI

HSCI

FCCU

FCCU

SMUI

SMUI

Sharedresource bus


Frame A

FE FE

BSGI

Figure 2-3 Uplink path for ISUP/INAP over MTP3/M2UA



2-4

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

BFII

BFII

IFMI

IFMI

IP IP

BSGI

Ethernet bus

SIUI

HSCI

SIUI

HSCI

FCCU

FCCU

SMUI

SMUI

Sharedresource bus


Frame A

FE FE

BSGI

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

BFII

BFII

IFMI

IFMI

FE FE

BSGI

Ethernet bus

SIUI

HSCI

SIUI

HSCI

FCCU

FCCU

SMUI

SMUI

Sharedresource bus


Frame A

FE FE

BSGI

Figure 2-5 Uplink path for ISUP/INAP over M3UA



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:

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.

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

BFII

BFII

IFMI

IFMI

IP IP

BSGI

Ethernet bus

SIUI

HSCI

SIUI

HSCI

FCCU

FCCU

SMUI

SMUI

Sharedresource bus


Frame A

FE FE

BSGI

Figure 2-6 Downlink path for ISUP/INAP over M3UA

1) The FCCU/FCSU transmits received messages to a BSGI through the Ethernet bus according to the BSGI module number of the associated M3UA link.

2) The BSGI processes the M3UA 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.



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



2-8

BFII

BFII

IFMI

IFMI

FE FE

BSGI

BSGI

CDBI

CDBI

Ethernet bus

SIUI

HSCI

SIUI

HSCI

FCCU

FCCU

SMUI

SMUI

Sharedresource bus


Frame A

FE FE

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 messages from a media gateway

2) The CDBI queries the correspondence table between media gateway domain name and pertaining FCCU/FCSU module number, and subsequently transfers messages to the FCCU/FCSU module responsible for managing the gateway or termination.

None

Notify messages from a media gateway

The BSGI dispatches messages to a pertaining FCCU/FCSU according to Request ID. For permanent event messages with Request ID 0, the BSGI transfers them to a CDBI which will query the FCCU/FCSU module number the termination belongs to and then transfer messages to that module.

The range of Request ID is assigned by the FCCU/FCSU.



2-9

Message type Path Remark

Delete Connection (DLCX) messages from a media gateway

The BSGI transfers messages to a CDBI. The CDBI queries the FCCU/FCSU module number the termination belongs to and then transfers messages to that module.

None

Response messages from a media gateway to SoftX3000

The BSGI dispatches messages to a pertaining FCCU/FCSU according to Transaction ID.

The range of Transaction ID is assigned by the 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.

BFII

BFII

IFMI

IFMI

IP IP

BSGI

Ethernet bus

SIUI

HSCI

SIUI

HSCI

FCCU

FCCU

SMUI

SMUI

Sharedresource bus


Frame A

FE FE

BSGI

Figure 2-8 Downlink path for MGCP/H.248 over UDP

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



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.

BFII

BFII

IFMI

IFMI

FE FE

MSGI

MSGI

CDBI

CDBI

SIUI

HSCI

SIUI

HSCI

FCCU

FCCU

SMUI

SMUI


Frame A

FE FE

Ethernet bus

Sharedresource bus

Figure 2-9 Uplink path in SoftX3000 for H.323


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.

Level-1 dispatch of H.323 RAS

The IFMI dispatches the H.323 RAS message to a specified MSGI according to data configuration.



2-11

Note:

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.

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.

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

Note:

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

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.

Admission Request (ARQ), a type of call related request

2) If the query is completed successfully, the MSGI dispatches the level-2 messages 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 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 (DRQ), Information Request (IRQ), and Bandwidth Request (BRQ)

The MSGI dispatches messages to an FCCU/FCSU which is determined according to manual data configurations.

Non-call related requests, such as Registration Request (RRQ) and Unregistration Request (URQ)

The MSGI dispatches messages in the same way as dispatching ARQs. First the MSGI queries the database of the local board to obtain a desired FCCU/FCSU module number. If the query fails, the MSGI turns to a CDBI for the FCCU/FCSU module number.



2-13

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 receipt of the found FCCU/FCSU module number returned by 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.

H.323 user call message

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 correspondence between Call ID and FCCU/FCSU. H.323 trunk call

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.



2-14

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.

BFII

BFII

IFMI

IFMI

IP IP

MSGI

SIUI

HSCI

SIUI

HSCI

FCCU

FCCU

SMUI

SMUI


Frame A

FE FE

MSGI

Ethernet bus

Sharedresource bus

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.

3) The MSGI dispatches messages to an appropriate IFMI according to the local IP address carried in the UDP packet to be delivered.


H.323 RAS




2-15

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.

3) The MSGI dispatches messages to an appropriate IFMI according to the local IP address carried in the TCP packet to be delivered.


H.323 CALL

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.

BFII

BFII

IFMI

IFMI

FE FE

MSGI

MSGI

CDBI

CDBI

Ethernet bus

SIUI

HSCI

SIUI

HSCI

FCCU

FCCU

SMUI

SMUI

Sharedresource bus


Frame A

FE FE

Figure 2-11 Uplink path for SIP over UDP



2-16


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:

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.

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 type Path

1) The MSGI queries the database on the local board for the correspondence between SIP User ID and FCCU/FCSU.

Register

2) If the query is completed successfully, the MSGI dispatches messages to the found FCCU/FCSU. 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.

SIP user call message

1) For the first message of a call, the MSGI queries the database on the local board for the correspondence between SIP User ID and FCCU/FCSU.



2-17

Message type Path

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.

SIP user call message

3) For subsequent messages of the same call, the MSGI dispatches them directly to the corresponding FCCU/FCSU according to the 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 between Call ID and FCCU/FCSU. SIP trunk call

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

BFII

BFII

IFMI

IFMI

IP IP

MSGI

Ethernet bus

SIUI

HSCI

SIUI

HSCI

FCCU

FCCU

SMUI

SMUI

Sharedresource bus


Frame A

FE FE

MSGI

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

BFII

BFII

IFMI

IFMI

FE FE

BSGI

SIUI

HSCI

SIUI

HSCI

FCCU

FCCU

SMUI

SMUI


Frame A

FE FE

BSGI

Ethernet bus

Sharedresource bus

Figure 2-13 Uplink path for DSS1 over IUA


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, 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-20

BFII

BFII

IFMI

IFMI

IP IP

BSGI

SIUI

HSCI

SIUI

HSCI

FCCU

FCCU

SMUI

SMUI


Frame A

FE FE

BSGI

Ethernet bus

Sharedresource bus

Figure 2-14 Downlink path for DSS1 over IUA

1) The FCCU/FCSU transmits received messages to a BSGI through the Ethernet 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.


4) 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.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-21

BFII

BFII

IFMI

IFMI

FE FE

BSGI

SIUI

HSCI

SIUI

HSCI

FCCU

FCCU

SMUI

SMUI


Frame A

FE FE

BSGI

Ethernet bus

Sharedresource bus

Figure 2-15 Uplink path for V5.2 over V5UA



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

BFII

BFII

IFMI

IFMI

IP IP

BSGI

SIUI

HSCI

SIUI

HSCI

FCCU

FCCU

SMUI

SMUI


Frame A

FE FE

BSGI

Ethernet bus

Sharedresource bus

Figure 2-16 Downlink path for V5.2 over V5UA

1) The FCCU/FCSU transmits received messages to a BSGI through the Ethernet bus according to the BSGI module number of the associated V5UA link.

2) The BSGI processes the V5UA 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.



Technical Manual – System Principle U-SYS SoftX3000 SoftSwitch System Chapter 3 Operation and Maintenance Principle


3-1

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.

Basic frame 0

SMUI

LAN Switch0 LAN Switch1

WS

BAM EmergencyworkstationStandby iGWB Active

iGWB

WS

To NMS

WANTo billingcenterWAN

HUB

Alarm box

SMUI

SIUI

SIUI

HSCI

HSCI

To billingcenter

WAN

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

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

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.

SoftX3000

Host softw

are

BAMsoftware

BAM

TerminalOAM

softwareWS

Local maintenancesystem

Upper NMS

iGWBsoftware

Billingcenter

Terminal System

iGWB

NMS

Communicationgateway

Figure 3-2 Logic structure of terminal system

Note:

For the principle of the billing gateway system, refer to Chapter 4 “Charging System” of this manual and U-SYS iGateway Bill User Manual.

For working principles of the NMS software, refer to HUAWEI iManager N2000 Fixed Network Integrated Management System NGN NM Solution User Manual.

The BAM and the iGWB communicate with SoftX3000 respectively. The former operates and maintains the system; the latter manages bills.

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.

Usually, the BAM and workstations communicate through Ethernet interface using TCP/IP. They can also communicate through serial port using the gateway tool.



3-4

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

Basic frame 0

SMUI

LAN Switch 0 LAN Switch 1

LAN

WS 0 WS 1

NIC1 NIC 2

NIC3

BAM

NIC1 NIC2

NIC3


SMUI

SIUI

SIUI

HSCI

HSCI

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

Warn

Maintain

Dataman

Statstics

Bill

SecurityManager

BAMService

ExchangeMMLServer

LogMan

SQLServer

SNMPAgent

DeviceMML GUI

WS

BAM

SNMPInterface

Monitor

Monitor

Shake hand

Figure 3-4 BAM software composition

The BAM software is composed of the following parts:

SQL Server stores the service data and provides database support for the service servers.

Logman logs the operation process and provides log query functions and malicious operation tracing functions for clients.

MML Server communicates with workstations, manages operator authorities, interprets commands input from workstations, and dispatches workstation commands.

SNMP Agent provides a standard SNMP interface to the NMS. 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.

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.

BAM Service monitors the Security Manager. It can also restart the BAM. Bill: A bill process responsible for collecting and sorting IP Centrex bills. Statistics is a traffic measurement process. It processes traffic measurement

data—creating traffic measurement tasks and querying measurement results. 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-7

Maintain is a maintenance process. It processes equipment maintenance commands—patching programs and tracing signaling.

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

Device

Remote WS Proxy Host

Internet

FirewallBAM

LAN Switch

Server Agent

Client Agent

LAN

LAN

Client Agent: Receiving data from remote maintenance workstations and transferring the data to the Server Agent

Server Agent: Receiving data from the Client Agent and transferring the data to the BAM

Proxy HOST: Proxy Server

Figure 3-5 Networking model of iWeb remote maintenance solution

iWeb remote maintenance system has the following features:

The original system does not need to be changed. You can remotely maintain the SoftX3000 through the iWeb remote maintenance system.

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.

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.

Before data transmission, iWeb encrypts data to ensure the security and compresses data to save the bandwidth.

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.

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

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.

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.

MML

You can conduct data configuration, performance management, and maintenance on SoftX3000 in the MML manner.

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 The log function provided by the BAM enables to correctly record all operations

performed by operators. SoftX3000 supports to isolate a private network from the public network, thereby

achieving screening from outside. The relationship among configured data is not seeable to user, which ensures the

consistency of the data. 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-10

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:

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.

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.

Signaling analysis



3-11

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

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

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

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

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.

Consistency check for supplementary service data is carried out periodically. Inconsistent data will be cleared as long as it is found.

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.

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.

Whenever the standby board is switched to be active, it actively sends a request to the BAM to restore the supplementary service data.



3-16

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

172.20.200.0BAM

172.30.200.0

LAN Switch 0 LAN Switch 1

HSCI

HSCI

SIUI

Slot 7 Slot 9

SIUI

Slot 6 Slot 8

Shared resource bus A Shared resource bus B

OSTA frame

Left half of frame

Back half of frame

Front half of frame

SMUI

CDBI

IFMI

BSGI

FCCU

SMUI

Networkadaptor A

Networkadaptor B

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

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

Note:

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.

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.

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:

Active SMUI: BAM network adaptor A→LAN Switch 0→HSCI in slot 9→SIUI in slot 6→SMUI in slot 6.

Standby SMUI: BAM network adaptor B→LAN Switch 1→HSCI in slot 7→SIUI in slot 8→SMUI in slot 8.

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:

Active SMUI: BAM network adaptor B→LAN Switch 1→HSCI in slot 7→SIUI in slot 8→SMUI in slot 8.



3-20

Standby SMUI: BAM network adaptor B→LAN Switch 1→HSCI in slot 7→SIUI in slot 6→SMUI in slot 6.

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.

Operator re-generates a data file. 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.

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

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:

When you add, modify, or delete data by running MML commands, BAM will automatically start data setting.

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:

Automatic backup of BAM data 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. 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-22

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

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

Providing command interfaces for operator to manage and maintain patches. 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.

Transferring patch files to SoftX3000. 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.

Processing patch related maintenance interfaces and related commands from the BAM.

Maintaining the consistency of the module patch state table with the BAM, according to patch commands typed by operator.

Receiving patch files, and detaching them to the patch area of SoftX3000. Writing patch files to a flash memory. Restoring patches whenever the system restarts. 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.

Idle: The initial state which indicates that the memory does not contain the software patch.

Deactivated: The software patch has been loaded to the patch area, but not been activated. The patch cannot be implemented.

Activated: The patch has been activated and can be implemented. This is a commissioning state.

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

Idle

ActiveRun

Deactive

LOAD

RMV

ACT DEA

RUN

RMVRMV

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.

Technical Manual – System Principle U-SYS SoftX3000 SoftSwitch System Chapter 4 Charging System


4-1

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:

SoftX3000 charging 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-2

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.

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.

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.

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.

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

Note:

A free call bill is generated in the following cases: The “charging category” in the subscriber attribute is set to Free. The “payer” in the associated charging case is set to Free. An answer signal, no charge (ANN) message from the opposite office is received.

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.

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

Free call statistical table: Carries out the statistic analysis of call times and duration of all free calls in the local office.

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.

SoftX3000

FCCU/FCSU

Call controlmodule

Ticket pool

iGWB Billing center

BAM

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

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.

U-PATH

BFII

HSCI

FCCU/FCSU

HSCI

Centrex ticketpool

Meter soft table

Ticket pool

FCCU/FCSU

Basic frame 0

Expansion frame n

LAN Switch inintegrated

configurationcabinet

iGWB

BAM

Billingcenter

Centrex ticketpool

Meter soft table

Ticket pool

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

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:

A host bill pool: Stores all bills to be sent to iGWB. A Centrex bill pool: Stores the detailed bills and metering soft table bills to be sent

to Centrex console—U-Path. 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.

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.

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

Caution:

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.

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.

Storing originaltickets

Storing final bills

FCCU/FCSUticket pool

Ticketreceiving

Ticket sorting

Formatconversion Sending bills

Billing center

Final bills

Original ticket

SoftX3000

iGWB

Figure 4-3 Bill processing diagram of iGWB



4-8

Note:

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.

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.

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:

Original bills 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-9

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

D:\FrontSave

X3KF

Origianl ticket file


Date



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:

Fixed network intelligent bill Fixed network ordinary detailed bill Fixed network metering bill Fixed network metering statistical bill Fixed network trunk duration statistical bill



4-11

Fixed network free call statistical bill 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 n

Channel 1

Final bill file

Date

Final bill file

Final bill file

Date

Final bill file

Final bill file

Date

Final bill file

Final bill file

Date

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

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.

Prefix

The optional prefix can be any string of characters. Usually the office name is used. By default, it is the character b.

File serial number

The mandatory file serial number is an incremental number from 00000001 to 99999999.

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 nFinal bill 4Final bill 3

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.

Technical Manual – System Principle U-SYS SoftX3000 SoftSwitch System Chapter 5 Alarm System


5-1

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.

Running state of the local board (normal/abnormal, active/standby) (Multi) frame synchronization/out-of-synchronization Clock Channel faults Online/offline

2) Software detection

Through software detection, logic errors beyond the control of hardware detection can be found.

Self-loop test of board CRC check Memory check Data consistency check



5-2

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 process

Other module

Alarm module

Alarmmanagement

system

Alarm box

Host BAM

WS

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:

Device penal on the workstation 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-3

Fault alarms: alarms generated due to faults of hardware components or exceptions of significant functions.

Recovery alarms: Alarms generated when the faulty components or abnormal functions are recovered. Each fault alarm has a recovery alarm.

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.

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.

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.

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.

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

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.

Real-time view and conditional real-time view of current alarms. Composite query of a particular category of alarms and dynamic update of

displayed results.



5-5

Detailed interpretation of alarm records and real-time display of handling methods. Printing of currently displayed alarms (in the alarm interpretation format) and

printing in a real-time way. Automatic paging message sent to maintenance personnel whenever an alarm is

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

LAN

WS

HSCI

SIUI

BFII

FCCU

FCSU

IFMI

BSGI

MSGI

CDBI

EPII

CKII

SMUI

ALUI

UPWR

RS485 serial port

Shared resource bus

PDF

Serial bus

Backplane

BAM Emergencyworkstation Alarm box

Serial bus

Shared resource bus

Figure 5-2 Alarm path for hardware faults from service processing frame



5-6

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.

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

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:

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.

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

LAN

HSCI

LAN

SIUI

MRIA

SMUI

ALUI

UPWR

FCCU

Share resource bus

Serial bus Backplane

SMUI

MRS frame

WSBAMEmergencyworkstation

AlarmboxBasic frame 0

Share resource bus

Figure 5-3 Hardware alarm reporting path for media resource frame

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.

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.

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

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

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.

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.

Technical Manual – System Principle U-SYS SoftX3000 SoftSwitch System Chapter 6 Environment Monitoring System


6-1

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.

-48V2

GND

PGND

-48V1 PG

ND

-48V1

-48V2

BG

ND

GND

PG

ND

-48V1

-48V2

BG

ND

PG

ND

-48V1

-48V2

BG

ND

（1）

(2)

（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-2

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 cabinet

(2)Service processing cabinet

(3) PDF

(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-3

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

9 3.3, 3.5, 4.3, 4.5, 5.4, 5.6, 6.4 and 6.6 Power cables for iGWB

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

LANSwitch0 SW3

LANSwitch1 SW2

KVM/LCD SW4

Basic frame 0 SW4, SW5

Integrated configuration cabinet

Expansion frame 1 SW5, SW6




Service processing cabinet




6-4

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.

SMUI

monitor board

Service processing frame

PDF

SIUI

SMUI

SIUI

RS485RS485

to OMC

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

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 frameUPWR

UPWR

UPWR

UPWR

ALUI

WSMU

SMUI

Power SupplyStatus

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

Service processingframe

Monitor

board

WSMU

SMUI

To OMC

Fan box

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.

SMUI

Monitor board

Serviceprocessing

frame

PDF

SIUI

SMUI

SIUI

RS485RS485

To OMC

Detection

interface

Sensor

Figure 6-6 Equipment room environment monitoring



6-7

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.

Technical Manual – System Principle U-SYS SoftX3000 SoftSwitch System Chapter 7 Clock Synchronization System


7-1

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 accuracy

Stratum-2 clock: ±4×10-7 Stratum-3 clock: ±4.6×10-6

Pull-in range

Stratum-2 clock: able to synchronize with the accuracy of ±4×10-7. Stratum-3 clock: able to synchronize with the accuracy of ±4.6×10-6.

Maximum frequency offset

Stratum-2 clock: 5×10-10/day Stratum-3 clock: 2×10-8/day

1 Network access parameter

Initial maximum frequency offset

Stratum-2 clock: <5×10-10/day Stratum-3 clock: <1×10-8/day



7-2

No. Item Specification

Ideal working status

MRTIE≤1ms

2 Long-term phase change Hold working

status

MRTIE (ns) ≤ a×s + (1/2)×b×s2+ c where, s indicates time with the unit as second. The unit of MRTIE is nanosecond (ns). 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

3 Clock working mode

Fast pull-in, locked, holdover and free-run.

4 Input jitter tolerance See Figure 7-1.

Note:

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

Maximum frequency offset is the maximum value of the relative frequency offset in a unit period during the consecutive running of the clock.

Pull-in range is the maximum frequency bandwidth of the input clock signals that the clock can lock.

MRTIE refers to the maximum peak-peak delay change of the tested clock to an actual reference clock during the test.



7-3

Y(U I)

102

X

With the s lope ratio of 20dB/10 oc taves

Peak-peak jitte r and wander am plitude (log s ca le)

A 0=36.9

101

A 1=1.5

A 2=0.2

1.2´10-5

1

10 20 2.4k 18k 100k f(Hz)

10-1

Y(U I)

102

X

With the s lope ratio of 20dB/10 oc taves

Peak-peak jitte r and wander am plitude (log s ca le)

A 0=36.9

101

A 1=1.5

A 2=0.2

1.2´10-5

1

10 20 2.4k 18k 100k f(Hz)

10-1

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

LAN

BAM WS

CKII

EPII

EPII

EPII

EPII

EPII

SMUI

BITS

E1

2MHz or 2MBit/s

8kHzH.110 bus

Serial portbus

Clockcable

Network cable

Expansionframe 1

Expansion frame n

8kHz

8kHz

8kHz

8kHz

H.110 bus

H.110 bus

2MHz

Basic frame

Serial portbus

Clockcable

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.

The CKII can connect with an external BITS clock reference source to obtain 2 MHz or 2 Mbit/s clock reference source.

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

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.

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.

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

...

CKII

Expansion frame 1

E1

Basic frame

(4)

(2) (1)

(3)

(5)

CKII

EPII

EPII

EPII

EPII

EPII

EPII

EPII

EPII

EPII

EPII (5)

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

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.

...

CKII (2)

(1)

(3)

(4)

CKII

EPII

EPII

EPII

EPII

EPII

EPII

EPII

EPII

EPII

EPII (4)

BITS0

BITS1

(1)

(3)

Expansion frame 8Expansion frame 1

Basic frame

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

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.

Technical Manual – System Principle U-SYS SoftX3000 SoftSwitch System Appendix A Format of Final Bills


A-1

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

Field Length(bytes) Offset Remark

net_type 1 0 11: fixed network bill 22: mobile network bill

bill_type 1 1

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

check_sum 1 2

Used for checking whether the bill is saved correctly, it is only a kind of checking mode, this field is not available in GB standard and occupies one byte.

partial_record_indicator 0.5 3

It is always 0,indicating a single record reserved when intelligent bill integrates with ordinary bill, therefore, it overlaps with charging record indicator 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-2


valid_indicato 0.125 3.5 It is always 0, indicating valid; it is 1, indicating invalid, equal to the record validity indicator in GB standard.

Spared 0.375 3.625 Spared bit

Intelligent Bill Related Flag 4 4

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 charging number address information 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-3


Record type 1 8 he same as that in GB standard. Refer to GB standard.

Charging Record Indicator 2 9

Used for AC operation in INAP, ranging 1-127. This field is not available in GB standard and is useless for the user.

Charging Category 2 11 It is the same as the category field of charging rate

in GB standard, ranging 1~1000.

Charging Mode 1 13 Equal to the charging/free of charge identifier in GB standard, 0 for free of charge, 1 for charging.

partial_record_indicator 1 14

The same as the partial record indicator field in GBstandard. 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 are as follows: 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

Caller number address information indicator

1 15

It is the same as the meanings of caller number address nature indicator in GB standard, and is a repetition of address nature indicator in caller number description. The actual meanings are as follows: 0 for spared, 1 for subscriber number, 2 for spared, 3 for domestic valid number , 4 for international valid number

Caller number description 14 19

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 and not checked, 1 for provided by the user, 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-4


Called number address information indicator

1 30

It is the same as the called number address nature indicator in GB standard, and is a repetition of address nature in called number description. The actual meanings are as follows: 0 for spared, 1 for subscriber number, 2 for spared, 3 for domestic valid number, 4 for international valid number

Called number description

14 31

Refer to the caller number description, but mask indicator and address presentation restriction indicator are not contained, and the 4 bits occupied by these 2 fields are spared bit.

Destination number address information indicator

1 45

It is the same as the translation number address nature indicator in GB standard, and is a repetition of address nature in destination number description. The actual meanings are as follows: 0 for spared, 1 for subscriber number, 2 for spared, 3 for domestic valid number, 4 for international valid number

Destination number description

14 46 Refer to the called number description.

paid-party indicator 1 60 Equal to the charge party ID indicator in GB

standard. Refer to GB standard for the meanings.

Designated charge number address information indicator

1 61 The same as the charge number address nature indicator. Refer to GB standard for specific meanings.

Designated charging number

11 62 BCD code

trunk_group_i n

2 73 It is the same as the incoming trunk group identifier.

trunk_group_ out

2 75 It is the same as the outgoing trunk group identifier.

ans_time 6 77

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 year, month, day, hour, minute, second in the character form in order.



A-5


Conversation end time

6 83

Equal to the conversation end time and time field in GB standard, but not to the accuracy of 100mm. It is in the YYMMDDHHMMSS format, these 6 bytes record year,month, day, hour, minute, second in the character form in order.

conversation_ time

4 89

4-byte BCD code, with the format as HHHMMSST, in which the meanings are as follows: HHH: 0-255 (hour(s)) MM : 0-59 (minute(s)) SS : 0-59 (second(s)) T : 0-9 (100 mm)

Conversation charge

4 93 The same as international charge field.

Traffic type 0.5 97

The same as the traffic type field in GB standard. At present, only local call, national originated call and international originated call are used. Refer to GB standard.

Release cause

0.5 97.5

Equal to the conversation end cause in GB standard. At present, only caller onhook, called onhook and abnormal end are used. Refer to GB standard.

caller_categor y

1.5 98 The same as that in GB standard.

Identifier 0.5 99.5 This field is invalid and will not be used.

Bearer capability

3 100

It includes selection type and selection value. The meanings are as follows: Selection type occupies one byte, and is not available in GB standard, and is useless to the subscriber. Selection value is equal to the bearer service in GBstandard, and is fixed at 1 and in character form. Refer to GB standard for it.



A-6


Service type 0.5 103

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

Tariff 4 104

Equal to the charge adjustment coefficient in GB standard. The structure in character form is shown as follows: Charge adjustment ratio: occupies 2 bytes Charge adjustment type: occupies 2 bytes, refer to GB standard for the meanings.

Premium 4 108 Equal to IN premium in GB standard, but only premium value is included, excluding premium type.

Transparent transmission charge parameter

20 112

RxFlux 4 132

TxFlux 4 136

Caller side media gateway/ terminal IP address

4 140

Caller side media gateway/ terminal IP address

4 144

Caller side soft switch equipment IP address

4 148

Called side soft switch equipment IP address

4 152



A-7

A.2 Fixed Ordinary Detail Bill Format

Field Length(Bytes)

(Offset) Remark


bill_type 1 1

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 0x05: record generated by TAX (not available in China) 0xF0: meter table bill 0xF1: meter table bill 0xF2: trunk duration statistics bill 0xF3: free call statistics bill 0xFF: alarm bill

check_sum 1 2

Used for checking whether the bill is saved correctly, it is only a kind of checking mode, this 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: 0: single record 1: the first part of record 2: the intermediate part of record 3: the last part of record

valid_indicator 0.125 3.5 It is always 0, indicating valid; it is 1, indicating invalid, equal to the record validity indicator in GB standard.

clock_indicator 0.125 3.625

Indicating that whether the clock is modified during the call process (such as whether the host time has been modified via BAM) 0 for YES, 1 for NO.

free_indicato 0.125 3.75 0 for free of charge; 1 for charging (at present the default is free call attempt)

call_attempt_indicator 0.125 3.875 0 for free call attempt; 1 for charged call attempt

complain_indicator 0.125 4 0 for no complaint; 1 for complaint



A-8

Field Length(Bytes)

(Offset) Remark

cama_indicator 0.125 4.125 0 for non-centralized charging; 1 for centralized charging

iis_credit_indicator 0.125 4.25 0 for non-credit call; 1 for credit call

spared 0.125 4.375 spared bit

charge_party_indicator 0.5 4.5

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 9: charging incoming trunk 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

ans_time 6 5

Indicating the start time of answering, the format is: YYMMDDHHMMSS YY:00-99(binary MM: 1-12 (binary) DD: 1-31 (binary) HH:0-23 (binary) MM: 0-59 (binary) SS: 0-59 (binary)

end_time 6 11

Indicating the time of conversation end, the format is: YYMMDDHHMMSS YY:00-99 (binary) MM: 1-12 (binary) DD: 1-31 (binary) HH:0-23 (binary) MM: 0-59 (binary) SS: 0-59 (binary)

conversation_time 4 17 the duration of this conversation recorded by switch, expressed with long integer

caller_dnset 1 21 Caller number network identifier

caller_address_nature Caller number

1 22 the caller number address nature:



A-9

Field Length(Bytes)

(Offset) Remark

address nature indicator

0 subscriber number caller number = local number1 spared 2 domestic valid number, caller number = toll area code + local number 3 international number, caller number =country code + toll area code + local number

caller_number 10 23 Caller number, expressed with compressed BCD code, and the surplus bits are filled with “0xF”

called_dnset 1 33 Called subscriber network identifier

called_address_nature 1 34

Called address nature: 0 subscriber number called number = local number 1 spared 2 domestic valid number, called number =toll area code + local number 3 international number, called number =country code + toll area code + local number

called_number 10 35

Called number, indicating the called number occurred at network side, compressed with compressed BCD code, and the surplus bits are filled with “0xF”.

centrex_group_number 2 45

Indicating Centrex group number of charging object, ranging 0-65535, in the case of non-Centrex group subscriber, the value is 0Xffff.

caller_ctx_number 5 47

Indicating the short number of caller within the Centrex group, expressed with BCD code, if this field is not available, each bit should be filled with “0xF”.

called_ctx_n umber

5 52

Indicating the short number of called party within the Centrex group, expressed with BCD code, if this field is not available, each bit should be filled with “0xF”.

trunk_group _in

2 57 The group number of incoming trunk, ranging 0-65535, if this call is not via incoming trunk, then it is expressed with 0xFFFF.

trunk_group_out 2 59 The group number of outgoing trunk, ranging 0-65535, if this call is not via outgoing trunk, then it is expressed with OxFFFF

caller_did 1 61 Equipment type of the calling party in local office

called_did 1 62 Equipment type of the called party in local office, ranging 0-255



A-10

Field Length(Bytes)

(Offset) Remark

caller_category 1 63

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) 07: operator, the language adopted after the negotiation of both parties 08: operator, the language adopted after the negotiation of both parties (Japanese) 09: domestic operator 0A: ordinary subscriber (toll-toll, toll– local) 0B: priority subscriber (toll-toll, toll-local, 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)

call_type 0.5 64

Values: 1. intra-office 2: incoming office 3. outgoing office 4: tandem 5: new service

gsvn 0.5 64.5

Values: 0: local office 1: local 2: local toll



A-11

Field Length(Bytes)

(Offset) Remark

3: national toll 4: international toll 5: new service 14: local CENTREX

termination_code 1 65 failure cause code

spared1 0.5 66

terminating_reason 0.5 66.5

0: caller off-hook; 1: called off-hook; 2: abnormal end

Calling SS during the call 7 67

Description of the supplementary services called during the call Note: The explanation of this field is not defined in GB standard, use 0 temporarily.

charging_case 2 74 The charging case value of this call, determined by the host charging setup data

rate 2 76 Charging unit price. The unit: minute

pulse_count 4 78 Receiving the number of charging pulse from the senior office

fee 4 82 4 82 The fee (including premium) calculated according to the host charging data. The unit: minute

connected_dnset 1 86 Connected number network identifier

connected_address_nature 1 87

Connected number address nature 0: subscriber number, connected number = local number 1. spared 2: national valid number, connected number = toll area code + local number 3: international number, connected number = country code+ toll area code + local number

connected_number 10 88

The connected number refers to the actual connection number of this call, mainly displaying the information, expressed in 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 exceptional case is: call transfer of the called subscriber, the connected number is the actual connection number after the transfer.



A-12

Field Length(Bytes)

(Offset) Remark

charge_dnset 1 98 Charge number network identifier

charge_address_nature 1 99

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 6: account card, C card 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

charge_number 10 100

Describing various kinds of subscriber number, card number, account in the compressed BCD mode (including Centrex group number), the surplus bits are filled with “0xF”.

bearer_service 1 110

Values: 1: circuit mode, 64Kbps unrestricted, 8KHZ structured bearer service 2: circuit mode, 64Kbps, 8KHZ structured bearer voice, including 100, 101, 102 and 103 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 structured bearer service type 8: circuit mode, 6X64Kbps unrestricted, 8KHZ structured bearer service type 9: circuit mode, 24X64Kbps unrestricted, 8KHZ



A-13

Field Length(Bytes)

(Offset) Remark

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

teleservice 1 111

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 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 38: 64Khz*9 image 39: 64Khz*10 image 40: 64Khz*11 image



A-14

Field Length(Bytes)

(Offset) Remark

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

CodeType 1 136

ITUT codec definition below 0: no indication 1: G.711 64 kbit/s A-law 2: G.711 64 kbit/s m-law 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 7: G.723.1 Annex A (silence suppression) 8: G.726 (ADPCM) 9: G.727 (Embedded ADPCM)



A-15

Field Length(Bytes)

(Offset) Remark

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/ segment)




A-16

Field Length(Bytes)

(Offset) Remark


A.3 Fixed Network Meter Table Bill Format

Field Length (byte) Offset Remark

Csn 4 0 Sequence of CDR

bill_type 1 4

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 0x04: records of ISDN/CTX 0x05: records generated by TAX (not provided domestically) 0xF0: meter table bill 0xF1: meter table statistics bill 0xF2: trunk occupation duration statistics bill 0xF3: statistics bill of free calls 0xFF: alarm bill

check_sum 1 5

Used for checking whether the bill is saved correctly. It is only a kind of check method, not 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 bill, the values are: 0: single record 1: the first part of the record 2: the middle part of the record 3: the last part of the record


Charge object 0.25 6.625 0: subscriber 1: incoming trunk 2: outgoing trunk

Spared 0.125 6.875



A-17


Number of meter tables 1 7 The number of the meter tables. It is currently 20.

Date and time of meter table generation 6 8

Indicating the date and time when the meter table is generated, the format is: YYMMDDHHMMSS YY:00-99 (binary) MM: 1-12(binary) DD: 1-31(binary) HH:0-23 (binary) MM: 0-59 (binary) SS: 0-59 (binary)

Dnset 1 14 Number network identifier

address_nature 1 15

Number address nature: 0: subscriber number, number = local number 1: spared 2: national valid number, number = toll area code + local number 3: international number, number = country code + toll area code + local number

Number 10 16 The subscriber number, expressed in compressed BCD code, and the surplus bits are filled with “0xF”.

Trunk group number 2 26 The charge objects are the trunk number and the trunk group number in the case of the outgoing trunk.

Module number 1 28 The number of the module that the subscriber or the trunk group belongs to

Subscriber equipment type 1 29 The equipment type of the subscriber meter

table: value range (0-255)

Equipment sequence number 2 30

The equipment sequence of the subscriber within the module 0-65534, 65535 is a void value

Value of meter table 1 2 32 The value accumulated on the table since the last meter table bill is generated

Call times of meter table 1 2 34 The call number accumulated on the table

since the last meter table bill is generated






A-18


































A-19


Value of meter table 13 2 80 The value accumulated on the table since the last meter. table bill is generated
























reserved 6 112



A-20

A.4 Fixed Network Meter Table Statistics Bill (statisticsMeterBill)



bill_type 1 1


check_sum 1 2


partial_record_ind icator 0.5 3

Indicating whether the bill is an independent record or it is a time segment record in the long bill, the values are: 0: single record 1: the first part of the record 2: the middle part of the record 3: the last part of the record


Spared 0.375 3.625

Number of meter tables 1 4 The number of the meter tables. It is currently 20.



A-21


Date and time of bill generation

6 5

Indicating the date and time when the meter table is generated, the format is: YYMMDDHHMMSS YY:00-99 (binary) MM: 1-12 (binary) DD: 1-31 (binary) HH:0-23 (binary) MM: 0-59 (binary) SS: 0-59 (binary)

Module number 1 11 The number of the module generating the meter table statistics bills, with the value range: 1-240

Call type 1 12

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

Value of meter table 1 2 13 The value accumulated on the table since the

last meter table bill is generated (same below)

Call times of meter table 1 2 15

The call number accumulated on the table since the last meter table bill is generated (same below)

Value of meter table 2 2 17


Value of meter table 3 2 21


There are totally 20 meter tables, and the detailed description will be omitted.



A-22

A.5 Fixed Network Trunk Occupation Duration Statistics Bill



bill_type 1 1


check_sum 1 2


Spared 0.5 3

valid_indicator 0.125 3.5

It is always 0, indicating valid; it is 1, indicating invalid, equal to the record validity indicator in GB standard.

Spared 1.375 3.625

Date and time of bill 6 5

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

Module number 1 11 The number of the module generating the trunk occupation duration statistics bills, with the valuerange of 1-240



A-23


Spared 1 12

Trunk group number 2 13

The charge objects are the trunk number and the trunk group number in the case of the outgoing trunk.

Incoming conversation duration

4 15 The conversation duration is calculated in the unit of seconds.

Incoming call times 2 19

Tandem conversation duration

4 21

Tandem call times 2 25

Outgoing conversation duration

4 27

Outgoing call times 2 31

A.6 Fixed Network Statistics Bill of Free Calls



bill_type 1 1




A-24


check_sum 1 2


Spared 0.5 3


Spared 1.375 3.625

Date and time of bill generation

6 5

Indicating the date and time when the meter table is generated, the format is: YYMMDDHHMMSS YY:00-99 (binary) MM: 1-12 (binary) DD: 1-31(binary) HH:0-23 (binary) MM: 0-59 (binary) SS: 0-59 (binary)

Module number 1 11 The number of the module generating the meter table statistics bills, with the value range of 1-240

Spared 1 12

Statistics value of free call duration 4 13 The statistics value of free call duration since the

last free call statistics bill is generated

Statistics value of free call times 2 17 The statistics value of free call times since the

last free call statistics bill is generated



A-25

A.7 Supplementary Service Bill



bill_type 1 1


check_sum 1 2


Spared 0.5 3


Spared 1.375 3.625

Service ending date and time 3 5

Indicating the date and time when the meter table is generated, the format is: YYMMDDHHMMSS YY:00-99 binary MM: 1-12 binary DD: 1-31 binary HH:0-23 binary MM: 0-59 binary SS: 0-59 binary



A-26


Service type 1 11

Service type: 0X02 CFU 0X03 CFB 0X04 CFNA 0X20 Centrex ICW

Caller number 10 12 The caller number, expressed in compressed BCD code, and the surplus bits are filled with “0xF”.

Charged party number indication 10 22

The charged party number, expressed in compressed BCD code, and the surplus bits are filled by “0xF”

Service initiating party number 10 32

The numbers triggering the services(BCD code)CF: The number dialed by the caller Centrex: The caller number ICW: The called number

Service accepting party number 10 42

The service ending numbers: CF: The forwarded number Centrex: The actual number of the called party ICW: The receiving/forwarding number designated by the subscriber

Service triggered times 1 52 Times of service triggered

Ending cause 2 53 The ending cause code

Service starting date and time 6 55 The service starting time

Paying method 1 61

Paying method: 1: charging by month 2: charging by quarter 3: charging by usage times

Service fee 4 62 The service fee

Conversation duration 4 66 The conversation duration

Technical Manual – System Principle U-SYS SoftX3000 SoftSwitch System Appendix B Acronyms and Abbreviations


B-1

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

DOPRA Distributed Object-Oriented Programmable Real-Time 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-2


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

ISUP Integrated Services Digital Network User Part/ISDN 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-3


N

NI Network Indicator

O

OPC Originating Point Code

OSTA HUAWEI Open Standards Telecom Architecture 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-4


W

WS WorkStation

Technical Manual – System Principle U-SYS SoftX3000 SoftSwitch System Index


i-1

Index

A alarem box, 5-3

alarem levels, 5-3

alarm categories, 5-2

alarm console, 5-4

alarm generation sytem, 5-2

alarm path for media resource frame, 5-6

alarm path for power distribution frame, 5-8

alarm path for service processing frame, 5-5

architecture of charging system, 4-4

B BAM, 1-2, 3-1

BAM software program, 3-6

bill pool, 4-4

bill storage directory, 4-9

billing center, 4-5

bottom-layer signaling processing module

BSGI, 1-5

FCSU, 1-4

MSGI, 1-5

bus

ethernet bus, 1-7

H.110 bus, 1-9

serial port bus, 1-11

shared resource bus, 1-6

C Centrex bill charging path, 4-7

charging path, 4-5

clock signal path when be locked by peer device, 7-6

clock signal path when locks peer device, 7-4

communication gateway software, 3-11

CRC check, 3-20

D data format conversion, 3-20

data setting, 3-20

data storage

BAM data, 3-14

host data, 3-14

supplementary service data, 3-15

detailed bill, 4-2

DSS1 signaling processing path, 2-17

E emergency workstation, 3-2

Ethernet dual planes, 1-8

F fault detection system, 5-1

feature of BAM

client/server structure, 3-7

high reliablilty, 3-7

final bile file name, 4-11

fixed IN bill format, A-1

fixed network trunk occupation duration statistics bill

format, A-20

fixed ordinary detail bill format, A-6

format of final bill file, 4-11

free call statistics bill format, A-21

G GUI, 3-9

H H.323 signaling processing path

H.323 CALL, 2-10

RAS, 2-10

hardware architecture

environment monitoring subsystem, 1-3



i-2

maintenance management subsystem, 1-2

service processing subsystem, 1-1

hardware composition, 1-1

I iGWB, 1-2, 3-2

iGWB processing path, 4-7

interface module

BFII, 1-4

CKII, 1-4

EPII, 1-4

IFMI, 1-4

IP address of boards, 3-18

iWeb, 3-7

L loading path, 3-16

logical architecture, 1-3

M M2UA signaling processing path, 2-3

M3UA signaling processing path, 2-5

meter table bill format, A-15

metering bill, 4-3

MGCP/H.248 signaling processing path, 2-7

MML, 3-9

monitoring environment principle, 6-6

monitoring fan principle, 6-6

monitoring PDF principle, 6-4

monitoring power supply principle, 6-5

N networking of terminal system, 3-1

NMS, 3-3

number and use of cables on PDF, 6-3

O offline billing, 4-1

online billing, 4-1

operation and maintenance module, 1-5

OSTA frames, 1-1

P patch number, 3-21

patch state transition, 3-24

power introduction module, 6-1

S security manage

account management, 3-14

locking the client, 3-14

specifying login time, 3-14

workstation management, 3-13

security management

command group, 3-13

service processing module

CDBI, 1-5

FCCU, 1-5

SIP signaling processing path, 2-14

software alarm reporting path, 5-8

software architecture of terminal system, 3-2

statistical bill, 4-3

statistics meter bill format, A-18

statum-2 clock, 7-1

statum-3 clock, 7-1

storage of final bills, 4-10

storage of original bills, 4-9

structure of clock system, 7-3

supplementary service bill format, A-23

system support module

HSCI, 1-4

SIUI, 1-4

SMUI, 1-4

T TDM signaling path, 2-1

technical specifications of clock sytem, 7-1

types of final bill, 4-11

U use of power controlling switches, 6-3



i-3

V V5UA signaling processing path, 2-18

version specific, 3-22

W workstation, 3-2

i.

2.8.2 downlink path 2-21 -...

Documents