System Principle(V200R008C01 01)

HUAWEI MSOFTX3000 Mobile SoftSwitch Center

V200R008C01

System Principle

Issue 01

Date 2009-02-10

Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

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

Huawei Technologies Co., Ltd.Address: Huawei Industrial Base

Bantian, LonggangShenzhen 518129People's Republic of China

Website: http://www.huawei.com

Email: [email protected]

Copyright © Huawei Technologies Co., Ltd. 2009. All rights reserved.No part of this document may be reproduced or transmitted in any form or by any means without prior writtenconsent of Huawei Technologies Co., Ltd. Trademarks and Permissions

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

Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

http://www.huawei.com

mailto:[email protected]

Contents

About This Document.....................................................................................................................1

1 System Architecture...................................................................................................................1-11.1 Hardware Structure.........................................................................................................................................1-2

1.1.1 Hardware Composition..........................................................................................................................1-21.1.2 General Physical Structure.....................................................................................................................1-31.1.3 Service Processing Subsystem...............................................................................................................1-61.1.4 Maintenance Management Subsystem...................................................................................................1-71.1.5 Environment Monitoring Subsystem.....................................................................................................1-7

1.2 Logical Structure.............................................................................................................................................1-71.2.1 General Logical Structure......................................................................................................................1-81.2.2 Processor Subsystem..............................................................................................................................1-81.2.3 Switching Subsystem.............................................................................................................................1-91.2.4 Electromechanical Subsystem................................................................................................................1-91.2.5 Equipment Management Subsystem......................................................................................................1-9

1.3 System Bus Structure......................................................................................................................................1-91.3.1 IPMB Bus.............................................................................................................................................1-101.3.2 Base Bus...............................................................................................................................................1-121.3.3 Fabric Bus............................................................................................................................................1-13

1.4 Software Structure.........................................................................................................................................1-141.4.1 Overview of Software Architecture.....................................................................................................1-141.4.2 Host Software.......................................................................................................................................1-151.4.3 OMU Software.....................................................................................................................................1-15

1.5 System Process..............................................................................................................................................1-161.5.1 Host Process.........................................................................................................................................1-161.5.2 Background Process.............................................................................................................................1-17

2 Service Processing Subsystem.................................................................................................2-12.1 Processing of Signaling over IP......................................................................................................................2-2

2.1.1 Processing of Signaling over M2UA.....................................................................................................2-22.1.2 Processing of Signaling over M3UA.....................................................................................................2-42.1.3 Processing of Signaling over BICC.......................................................................................................2-52.1.4 Processing of Signaling over SIP...........................................................................................................2-72.1.5 Processing of Signaling over H.248.......................................................................................................2-8

HUAWEI MSOFTX3000 Mobile SoftSwitch CenterSystem Principle Contents

Issue 01 (2009-02-10) Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

i

3 Maintenance Management Subsystem..................................................................................3-13.1 Hardware Architecture....................................................................................................................................3-2

3.1.1 OMU.......................................................................................................................................................3-33.1.2 iGWB.....................................................................................................................................................3-33.1.3 Local Maintenance Terminal (LMT).....................................................................................................3-4

3.2 Software Architecture.....................................................................................................................................3-43.2.1 OMU Software.......................................................................................................................................3-53.2.2 LMT Software........................................................................................................................................3-8

3.3 Security Management....................................................................................................................................3-103.3.1 Command Groups................................................................................................................................3-103.3.2 Workstation Management....................................................................................................................3-113.3.3 Account Management..........................................................................................................................3-113.3.4 Login Time...........................................................................................................................................3-113.3.5 Lock Time............................................................................................................................................3-11

3.4 Data Management.........................................................................................................................................3-113.4.1 Storing OMU Data...............................................................................................................................3-123.4.2 Storing Host Data.................................................................................................................................3-123.4.3 Operating Data.....................................................................................................................................3-12

3.5 Loading Data.................................................................................................................................................3-143.5.1 Loading Options...................................................................................................................................3-143.5.2 Principles for Loading Data.................................................................................................................3-153.5.3 Procedure for Loading Data.................................................................................................................3-16

3.6 Software Patch Management.........................................................................................................................3-173.6.1 Basic Concepts.....................................................................................................................................3-173.6.2 Key Features.........................................................................................................................................3-183.6.3 Architecture..........................................................................................................................................3-193.6.4 Implementation.....................................................................................................................................3-20

4 Environment Monitoring Subsystem.....................................................................................4-14.1 Power Supply..................................................................................................................................................4-2

4.1.1 Power Input Unit....................................................................................................................................4-24.1.2 Power Distribution Unit.........................................................................................................................4-3

4.2 Monitoring Power Supplies.............................................................................................................................4-44.3 Monitoring Fan Boxes.....................................................................................................................................4-54.4 Monitoring the Environment of a Telecommunications Room......................................................................4-6

5 Alarm Management System.....................................................................................................5-15.1 Subsystems of the Alarm Management System .............................................................................................5-2

5.1.1 Fault Detection Subsystem.....................................................................................................................5-25.1.2 Alarm Generation Subsystem.................................................................................................................5-2

5.2 Alarm Severity and Alarm Type.....................................................................................................................5-35.2.1 Alarm Severity.......................................................................................................................................5-35.2.2 Alarm Type............................................................................................................................................5-4

5.3 Alarm Box and Alarm Console.......................................................................................................................5-4

ContentsHUAWEI MSOFTX3000 Mobile SoftSwitch Center

System Principle

ii Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

Issue 01 (2009-02-10)

5.3.1 Alarm Box..............................................................................................................................................5-45.3.2 Alarm Console........................................................................................................................................5-5

5.4 Alarm Report Path...........................................................................................................................................5-55.4.1 Hardware Alarm Report Path.................................................................................................................5-55.4.2 Software Alarm Report Path..................................................................................................................5-6

5.5 Alarm Database...............................................................................................................................................5-65.5.1 Location of the Alarm Database.............................................................................................................5-75.5.2 Alarm Limitation Policy.........................................................................................................................5-7

6 Time Synchronization...............................................................................................................6-16.1 NTP Function..................................................................................................................................................6-2

6.1.1 Definition of NTP...................................................................................................................................6-26.1.2 Working Principles of NTP....................................................................................................................6-26.1.3 Networking of NTP................................................................................................................................6-4

6.2 Time Calibration Principles and Procedure....................................................................................................6-5

7 CDR and Charging.....................................................................................................................7-17.1 Basic Concepts................................................................................................................................................7-2

7.1.1 Charging Scheme...................................................................................................................................7-27.1.2 CDR Classification.................................................................................................................................7-37.1.3 CDR Interface........................................................................................................................................7-37.1.4 CDR Encoding.......................................................................................................................................7-4

7.2 CDR Generation..............................................................................................................................................7-47.2.1 CDR Generation Mechanism.................................................................................................................7-57.2.2 CDR Generation Process........................................................................................................................7-67.2.3 CDR Generation Scenarios....................................................................................................................7-8

7.3 CDR Delivery................................................................................................................................................7-147.3.1 CDR Delivery Process.........................................................................................................................7-147.3.2 Delivery Modes of Original CDRs.......................................................................................................7-157.3.3 Delivery Modes of Final CDRs............................................................................................................7-15

7.4 CDR Storage.................................................................................................................................................7-167.4.1 Storage of Original CDRs....................................................................................................................7-167.4.2 Storage of Final CDRs.........................................................................................................................7-17

7.5 CDR Backup.................................................................................................................................................7-187.5.1 Backup of Original CDRs....................................................................................................................7-197.5.2 Backup of Final CDRs (the First Copy)...............................................................................................7-19

8 Final CDRs...................................................................................................................................8-18.1 Types of Final CDRs.......................................................................................................................................8-28.2 Format of Final CDRs.....................................................................................................................................8-2

HUAWEI MSOFTX3000 Mobile SoftSwitch CenterSystem Principle Contents


iii

Figures

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

HUAWEI MSOFTX3000 Mobile SoftSwitch CenterSystem Principle Figures


v

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

FiguresHUAWEI MSOFTX3000 Mobile SoftSwitch Center

System Principle

vi Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

Issue 01 (2009-02-10)

Tables

Table 1-1 Network cable connections between subracks.....................................................................................1-6Table 4-1 Mappings between the cabinet components and the switches.............................................................4-4Table 7-1 Generation scenarios of original CDRs................................................................................................7-9

HUAWEI MSOFTX3000 Mobile SoftSwitch CenterSystem Principle Tables


vii

About This Document

PurposeThis document describes the functional structure and working principles of theMSOFTX3000 (hereinafter referred to as the MSOFTX3000).

After reading this document, you should be able to know about the architecture and workingprinciples of various subsystems of the MSOFTX3000.

Related VersionsThe following table lists the product versions related to this document.

Product Name Version

MSOFTX3000 V200R008C01

Intended AudienceThe intended audiences of this document are:

l Network planning engineers

l Network administrators

OrganizationThis document consists of 8 chapters and is organized as follows.

Chapter Description

1 System Architecture This chapter describes the MSOFTX3000 with respect tothe hardware structure, logical structure, and softwarestructure.

2 Service ProcessingSubsystem

This chapter describes the service processing subsystemsof the MSOFTX3000 with respect to the structure,functions, and internal processing.

HUAWEI MSOFTX3000 Mobile SoftSwitch CenterSystem Principle About This Document


1

Chapter Description

3 Maintenance ManagementSubsystem

This chapter describes the maintenance managementsubsystem of the MSOFTX3000 with respect to thenetworking, structure, functions, and internal processing.

4 Environment MonitoringSubsystem

This chapter describes the environment monitoringsubsystem and the power supply system of theMSOFTX3000 with respect to the structure and functions.

5 Alarm Management System This chapter describes the alarm subsystem of theMSOFTX3000 with respect to the structure, compositionand briefs the alarm type, alarm level, alarm box, alarmconsole, and the report paths of hardware alarms andsoftware alarms.

6 Time Synchronization This chapter describes the clock synchronization system ofthe MSOFTX3000 with respect to the features,specifications, and implementation principles of clocksynchronization.

7 CDR and Charging This chapter describes the billing system of theMSOFTX3000 with respect to the structure,implementation principles, and storage of original CDRsand final CDRs.

8 Final CDRs This chapter presents the formats of the final CDRs intables.

Conventions

Symbol ConventionsThe following symbols may be found in this document. They are defined as follows.

Symbol Description

Indicates a hazard with a high level of risk which, if not avoided,will result in death or serious injury.

Indicates a hazard with a medium or low level of risk which, ifnot avoided, could result in minor or moderate injury.

Indicates a potentially hazardous situation that, if not avoided,could cause equipment damage, data loss, and performancedegradation, or unexpected results.

Indicates a tip that may help you solve a problem or save yourtime.

Provides additional information to emphasize or supplementimportant points of the main text.

About This DocumentHUAWEI MSOFTX3000 Mobile SoftSwitch Center

System Principle

2 Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

Issue 01 (2009-02-10)

General ConventionsConvention Description

Times New Roman Normal paragraphs are in Times New Roman.

Boldface Names of files, directories, folders, and users are in boldface.For example, log in as user root.

Italic Book titles are in italics.

Courier New Terminal display is in Courier New.

Command ConventionsConvention Description

Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italic.

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

{ x | y | ... } Alternative items are grouped in braces and separated by verticalbars. One is selected.

[ x | y | ... ] Optional alternative items are grouped in square brackets andseparated by vertical bars. One or none is selected.

{ x | y | ... } * Alternative items are grouped in braces and separated by verticalbars. A minimum of one or a maximum of all can be selected.

[ x | y | ... ] * Optional items are grouped in brackets and separated by verticalbars. Several items or no item can be selected.

GUI ConventionsConvention Description

Boldface Buttons, menus, parameters, tabs, window, and dialog titles arein boldface. For example, click OK.

> Multi-level menus are in boldface and separated by the ">" signs.For example, choose File > Create > Folder.

Keyboard OperationFormat Description

Key Press the key. For example, press Enter and press Tab.

Key 1+Key 2 Press the keys concurrently. For example, pressing Ctrl+Alt+A means the three keys should be pressed concurrently.

HUAWEI MSOFTX3000 Mobile SoftSwitch CenterSystem Principle About This Document


3

Format Description

Key 1, Key 2 Press the keys in turn. For example, pressing Alt, A means thetwo keys should be pressed in turn.

Mouse OperationAction Description

Click Select and release the primary mouse button without moving thepointer.

Double-click Press the primary mouse button twice continuously and quicklywithout moving the pointer.

Drag Press and hold the primary mouse button and move the pointerto a certain position.

Update HistoryUpdates between document versions are cumulative. Therefore, the latest document versioncontains all updates made to previous versions.

Updates in Issue 01 (2009-02-10)Initial release

About This DocumentHUAWEI MSOFTX3000 Mobile SoftSwitch Center

System Principle

4 Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

Issue 01 (2009-02-10)

1 System Architecture

About This Chapter

The MSOFTX3000 is a system built on the Open Standards Telecom Architecture Platform(OSTA 2.0 platform).

1.1 Hardware StructureThe MSOFTX3000 comprises the power subrack, service processing subrack, serviceprocessing unit, master rack monitoring unit (MRMU), local maintenance terminal (LMT), andLAN switch.

1.2 Logical StructureThe MSOFTX3000 can be viewed as a system comprised of multiple logical subsystems fromthe service logic perspective.

1.3 System Bus StructureThe system buses connect various subsystems of the MSOFTX3000. The subsystems exchangeinformation and communicate with each other through the system buses.

1.4 Software StructureThe MSOFTX3000 adopts the distributed software structure. The software functions aredistributed among the server boards and can be configured flexibly to meet the actual networkingrequirements.

1.5 System ProcessThe system processes of the MSOFTX3000 can be classified into host process and OMU process.

HUAWEI MSOFTX3000 Mobile SoftSwitch CenterSystem Principle 1 System Architecture


1-1

1.1 Hardware StructureThe MSOFTX3000 comprises the power subrack, service processing subrack, serviceprocessing unit, master rack monitoring unit (MRMU), local maintenance terminal (LMT), andLAN switch.

1.1.1 Hardware CompositionThe hardware of the MSOFTX3000 consists of the following: cabinet, power subrack, servicesubrack, board, keyboard & video & mouse & switcher (KVMS), optionally MRMU, and LANSwitch.

1.1.2 General Physical StructurePhysically, the MSOFTX3000 comprises various hardware components and cable connections.

1.1.3 Service Processing SubsystemThe service processing subsystem, also known as the host, is the core of the MSOFTX3000. Itcomprises service processing subracks and service processing boards. It fulfills functions suchas service processing and resource management.

1.1.4 Maintenance Management SubsystemThe maintenance management subsystem, also known as the OMU, is composed of the activeand standby OMU boards, active and standby iGWB boards, LMT, and communication devices.It fulfills functions such as O&M and CDR management.

1.1.5 Environment Monitoring SubsystemThe environment monitoring subsystem is comprised of the fan monitoring module of eachservice processing subrack, and the power supply monitoring module and MRMU (optional) ofeach cabinet. It is designed to ensure that the MSOFTX3000 operates in a normal environment.

1.1.1 Hardware CompositionThe hardware of the MSOFTX3000 consists of the following: cabinet, power subrack, servicesubrack, board, keyboard & video & mouse & switcher (KVMS), optionally MRMU, and LANSwitch.

Figure 1-1 shows the hardware composition of the MSOFTX3000.

1 System ArchitectureHUAWEI MSOFTX3000 Mobile SoftSwitch Center

System Principle

1-2 Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

Issue 01 (2009-02-10)

Figure 1-1 Hardware composition of the MSOFTX3000

Cabinet

PDB

4

2

3

1

KVMS

MRMU

LAN Switch5

6

Subrack

1.1.2 General Physical StructurePhysically, the MSOFTX3000 comprises various hardware components and cable connections.

Figure 1-2 shows the hardware configuration of the MSOFTX3000.



1-3

Figure 1-2 Hardware configuration of the MSOFTX3000

Power distribution box(3U)

Subrack 1(14U)

LAN Switch cabling trough(1U)

MRMU(1U)LAN Switch 1(1U)

LAN Switch cabling trough(1U)LAN Switch 0(1U)

Subrack 0(14U)

Filler panel(3U)

Filler panel(3U)

Filler panel(3U)

KVMS (1U)

Integrated configuration cabinet(46U)


System Principle


Issue 01 (2009-02-10)

Figure 1-3 shows the physical structure and connections of the MSOFTX3000.

Figure 1-3 Physical structure of the MSOFTX3000

Local maintenanceterminal

SMM

SWU

SWU

SWI

SWI

SMM

SMM

SWU

SWU

SWI

SWI

SMM

Monitoringcenter

Bearernetwork

LAN Switch LAN Switch

Networkmanagemen

t center

Billingcenter

1#

2# - 3#

Service processingsubsystem

SMM

UPB

UPB

UPB

UPB

SWU

SWU

UPB

UPB

USI

USI

USI

SWI

SWI

USI

USI

SMM

0#

USI

The MSOFTX3000 consists of the following subsystems:l Service processing subsystem

l Maintenance management subsystem

l Environment monitoring subsystem

The subracks of the MSOFTX3000 are directly connected to each other. The principles forinterconnection between subracks are as follows:

l All the network cables used for interconnection between subracks are connected to subrack0#.

l Ethernet communication is set up on both the Fabric and Base planes to implement dual-plane Ethernet communication.

Table 1-1 presents the network cable connections between subracks.



1-5

Table 1-1 Network cable connections between subracks

Boards inSubrack0#

Plane ofSubrack0#

NetworkPort inSubrack0#

Connect-toSubrack

Connect-to Board

Connect-to Plane

Connect-toNetworkPort

SWI in slot06

FABRIC 7 1# SWI in slot06

FABRIC 7

SWI in slot06

BASE 7 SWI in slot06

BASE 7

SWI in slot07

FABRIC 7 SWI in slot07

FABRIC 7

SWI in slot07


BASE 7

SWI in slot06


FABRIC 7

SWI in slot06


BASE 7

SWI in slot07


FABRIC 7

SWI in slot07


BASE 7

SWI in slot06


FABRIC 7

SWI in slot06


BASE 7

SWI in slot07


FABRIC 7

SWI in slot07


BASE 7

1.1.3 Service Processing SubsystemThe service processing subsystem, also known as the host, is the core of the MSOFTX3000. Itcomprises service processing subracks and service processing boards. It fulfills functions suchas service processing and resource management.

Inter-Device Communication

The communication of service processing subsystem consists of three parts:

l Communication between subracks: The subracks communicate with each other through thenetwork connections between the WSMUs in the basic subrack and the extended subracks.


System Principle


Issue 01 (2009-02-10)

The communication is carried out through dual planes, namely, the Fabric and the Baseplanes.

l Communication between the host and the external equipment: The host communicates withthe external equipment through IP, TDM, and ATM interfaces. (MSOFTX3000V2R8C1provides only the IP interface.)

l Communication between the host and the OMU: The OMU, iGWB, and XPTU modulesare deployed on the boards in the configuration cabinet. They communicate with the hostthrough the internal bus.

System CapacityThe system capacity depends on the number of configured service processing subracks.Depending on the actual conditions, one or two service processing subracks can be configured.This can fully meet the requirements for smooth expansion.

1.1.4 Maintenance Management SubsystemThe maintenance management subsystem, also known as the OMU, is composed of the activeand standby OMU boards, active and standby iGWB boards, LMT, and communication devices.It fulfills functions such as O&M and CDR management.

The communication of the maintenance management subsystem consists of three parts:

l Communication between the maintenance management subsystem and the host: The OMUboards and iGWB boards communicate with the host through the internal Base bus.

l Communication between the LMT and the OMU and iGWB: The active and standbyOMUs and iGWBs are connected to the LAN switch using network cables. The LMTcommunicates with the OMUs and the iGWBs using TCP/IP in client/server mode. TheOMU also provides NM interfaces externally through the LAN switch.

l Communication between the OMU and the billing center: The active and the standbyiGWBs respectively provide a GE interface to the billing center.

1.1.5 Environment Monitoring SubsystemThe environment monitoring subsystem is comprised of the fan monitoring module of eachservice processing subrack, and the power supply monitoring module and MRMU (optional) ofeach cabinet. It is designed to ensure that the MSOFTX3000 operates in a normal environment.

1.2 Logical StructureThe MSOFTX3000 can be viewed as a system comprised of multiple logical subsystems fromthe service logic perspective.

1.2.1 General Logical StructureLogically, the MSOFTX3000 is composed of the service processing subsystem, switchingsubsystem, electromechanical subsystem, and equipment management subsystem.

1.2.2 Processor SubsystemThe processor subsystem fulfills the arbitration and service processing functions of the system.

1.2.3 Switching SubsystemThe switching subsystem fulfills the data exchange function in the system.



1-7

1.2.4 Electromechanical SubsystemThe electromechanical subsystem fulfills the power supply function of the system.

1.2.5 Equipment Management SubsystemThe equipment subsystem is comprised of the shelf management modules (SMMs), subrack datamodules (SDMs), and baseboard management controllers (BMCs) on various blade serverboards and modules. It fulfills functions such as status monitoring, management, andmaintenance of the hardware and management of alarms and statistics.

1.2.1 General Logical StructureLogically, the MSOFTX3000 is composed of the service processing subsystem, switchingsubsystem, electromechanical subsystem, and equipment management subsystem.

As shown in Figure 1-4, the switching subsystem acts as the pivot and the processor subsystemacts as the core. They, together with the electromechanical subsystem and equipmentmanagement subsystem, constitute a powerful service processing platform.

Figure 1-4 Logical structure of the MSOFTX3000

Backplane

SWU/SWI

SWU/SWI

SMM/SDM

SMM/SDM

FAN

FAN

Switchingsubsystem

Equipment managementsubsystem

Electromechanicalsubsystem

Fabric

BASE

IPMB

UPB/USI

UPB/USI

UPB/USI

UPB/USI

UPB/USI

UPB/USI

Service processingsubsystem

……

……

PEM

PEM

NOTE

SPM: The service processing module (SPM) is comprised of the UPB (front board) and the USI (backboard).

1.2.2 Processor SubsystemThe processor subsystem fulfills the arbitration and service processing functions of the system.

The processor subsystem is comprised of blade server boards, that is, UPBs. Designed with high-performance and multi-core processors, the blade server boards can deliver powerful processingcapability. In addition, they can provide abundant service interfaces through the mapping rearinterface boards. The blade server boards can be installed with different software to function asthe service processing boards as well as the OMU and the iGWB.


System Principle


Issue 01 (2009-02-10)

1.2.3 Switching SubsystemThe switching subsystem fulfills the data exchange function in the system.

The switching subsystem is comprised of the the switching units (SWUs, front boards) andswitching interface units (SWIs, back boards), which are compliant with PCI IndustrialComputers Manufacturers Group (PICMG) 3.0 and 3.1 specifications. Designed with a dual-star structure, the switching subsystem fulfills functions such as system control and dataexchange and interconnection at the service plane.

1.2.4 Electromechanical SubsystemThe electromechanical subsystem fulfills the power supply function of the system.

The electromechanical subsystem is comprised of the power distribution module, fan controlmodule, and system backplane. The power distribution module provides redundant backuppower supplies and power filters for the system. The fan control module monitors and controlsthe temperature of the equipment. The backplane provides power inputs and signalinterconnection for various boards in the subrack.

1.2.5 Equipment Management SubsystemThe equipment subsystem is comprised of the shelf management modules (SMMs), subrack datamodules (SDMs), and baseboard management controllers (BMCs) on various blade serverboards and modules. It fulfills functions such as status monitoring, management, andmaintenance of the hardware and management of alarms and statistics.

1.3 System Bus StructureThe system buses connect various subsystems of the MSOFTX3000. The subsystems exchangeinformation and communicate with each other through the system buses.

As shown in Figure 1-5, the MSOFTX3000 consists of the following types of buses:

l IPMB bus

l Base bus

l Fabric bus



1-9

Figure 1-5 System bus structure of the MSOFTX3000

Serial

IPMB

BASE

FABRIC

TDM

PDB

SWI

SWU

SWU

SMM

SMM

UPB

USIor

ETI

UPB

USIor

ETI

UPB

USIor

ETI

UPB

USIor

ETI

UPB

USIor

ETI

UPB

USIor

ETI

UPB

USIor

ETI

UPB

USIor

ETI

UPB

USIor

ETI

UPB

USIor

ETI

UPB

USIor

ETI

UPB

USIor

ETI

SWI

SDM

SDM

FAN

FAN

PEM

PEM

FABRIC

BASE

IPMB

TDM

1.3.1 IPMB BusIPMS bus is the equipment management bus of the entire system. It connects all the modulesand boards. The SMM manages the hardware in the subrack through the IPMB bus.

1.3.2 Base BusThe Base bus is located on the management and control plane of the system. It provides a channelfor software loading, alarm reporting, and maintenance message delivery.

1.3.3 Fabric BusThe Fabric bus provides a data channel for the system service plane. It transmits the serviceinformation of the system.

1.3.1 IPMB BusIPMS bus is the equipment management bus of the entire system. It connects all the modulesand boards. The SMM manages the hardware in the subrack through the IPMB bus.

Function

The SMM is the management module of the OSTA2.0 subrack. It manages all the boards andmodules in the subrack. The IPMB bus is the equipment management bus of the entire system.Through the IPMB bus, the SMM fulfills functions such as equipment management, eventmanagement, asset management, remote maintenance, configuration restore, energy savingcontrol, power monitoring, and fan speed adjustment. Figure 1-6 shows the connections of theIPMB buses.


System Principle


Issue 01 (2009-02-10)

Figure 1-6 Connections of IPMB buses

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SWU

SWI

SWU

SWI

FAN FAN

SMM

SDM

SMM

SDM

PDBSerialIPMB

IPMS bus is the equipment management bus of the entire system, which connects all the modulesand boards. The SMM is the core of the entire management system. It communicates with theintelligent platform management controller (IPMC) of the board, fan frame, and PDF throughIPMB buses to issue monitoring commands and report messages.

Through the connections between the IPMB buses and the SMM, the system implements themonitoring and management functions of the field replaceable unit (FRU). The IPMC of theFRU detects the temperature, voltage and reset of a board, the presence and rotating speed of afan, and the voltage and current of the power distribution box. When detecting an error, theIPMC reports an alarm to the SMM.

ImplementationA dual-star and dual-bus topology is adopted for the IPMB bus. The implementation is asfollows:

l Each SMM provides 40 IPMB interfaces to connect to the BMCs of various boards andmodules in the subrack.

l Each board and module provides two IPMB interfaces to connect to the IPMB buses of thesystem so that they can communicate with the SMM.

l The two SMMs connect to each other through two IPMB buses for the data synchronization.



1-11

1.3.2 Base BusThe Base bus is located on the management and control plane of the system. It provides a channelfor software loading, alarm reporting, and maintenance message delivery.

FunctionThe SWU is the switching core of the Base plane. It implements information exchange on thesystem control plane and provides external interfaces of the Base plane. All boards connect tothe SWU over the Base plane. The SWU exchanges maintenance messages among all the boards.Figure 1-7 shows the connections of the Base buses.

Figure 1-7 Connections of the Base buses

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SWU

SWI

SWU

SWI

SMM

SDM

SMM

SDM

BASE

ImplementationA dual-star topology is adopted for the Base bus. The implementation is as follows:

l Each SWU provides twenty-four 10/100/1000M BASE-T Base interfaces. The planning ofthe interfaces is as follows:– 12 interfaces: connected to 12 UPBs

– 2 interfaces: connected to the active and the standby SMMs

– 1 interface: used to connect the active and the standby SWUs

– 4 interfaces: used to connect external equipment


System Principle


Issue 01 (2009-02-10)

– 5 interfaces: reserved

l The SMM and each UPB provide two Base interfaces to connect to the dual buses on theBase plane so that system information can be exchanged through the SWU.

1.3.3 Fabric BusThe Fabric bus provides a data channel for the system service plane. It transmits the serviceinformation of the system.

Function

The SWU is the switching core of the Fabric plane. It implements information exchange on thesystem service plane and provides external interfaces. All UPBs connect to the SWU over theFabric plane. They exchange service messages through the SWU. Figure 1-8 shows theconnections of the Fabric buses.

Figure 1-8 Connections of the Fabric buses

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SPM

UPB

USI

SWU

SWI

SWU

SWIFabric

Implementation

A dual-star topology is adopted for the Fabric bus. The implementation is as follows:

l Each SWU provides twenty-four 10/100/1000M BASE-BX Fabric bus interfaces. Theplanning of the interfaces is as follows:



1-13

– 12 interfaces: connected to 12 UPBs

– 1 interface: connected to the other SWU

– 4 interfaces: used to connect to the external equipment

– 5 interfaces: reserved

l Each UPB provide two Fabric interfaces to connect to the dual buses on the Fabric planeso that system information can be exchanged through the SWU.

1.4 Software StructureThe MSOFTX3000 adopts the distributed software structure. The software functions aredistributed among the server boards and can be configured flexibly to meet the actual networkingrequirements.

1.4.1 Overview of Software ArchitectureThe MSOFTX3000 software consists of the host software and the OMU software.

1.4.2 Host SoftwareThe host software adopts a layered modular design and consists of the following parts frombottom to top: operating system, middleware, and application software.

1.4.3 OMU SoftwareThe OMU software consists of the OMU, LMT, WebUI, and iGWB. The OMU is distributedon boards and the LMT is distributed on workstations. The OMU software fulfills functions suchas man-machine interaction and equipment management.

1.4.1 Overview of Software ArchitectureThe MSOFTX3000 software consists of the host software and the OMU software.

Figure 1-9 shows the overall software architecture of the MSOFTX3000.

Figure 1-9 Overall software architecture of the MSOFTX3000

Operating system

Middleware

DevicemanagementSignaling bearer

Protocol processing

Service processingDatabase

Operating system

Database software

Hostsoftware

Exchange

PerformanceBill

AlarmMaintenance

GUIMML

XPTUiGWB

Communication

Middleware

Communication

Differentiated by location, the MSOFTX3000 software can be classified into host software andOMU software.


System Principle


Issue 01 (2009-02-10)

l The host software is distributed on the boards in the service processing subrack. The hostsoftware performs the functions such as communication, signaling transmission, equipmentmanagement, memory database implementation, and load balancing.

l The OMU software consists of the OMU, LMT, and WebUI. The OMU is distributed onboards and the LMT and WebUI are distributed on workstations. The OMU software fulfillsfunctions such as man-machine interaction and equipment management.

1.4.2 Host SoftwareThe host software adopts a layered modular design and consists of the following parts frombottom to top: operating system, middleware, and application software.

Operating SystemThe MSOFTX3000 runs the Linux operating system.

MiddlewareThe middleware of the MSOFTX3000 is the DOPRA plug-in software platform developed byHuawei. It adopts the middleware technology to shield the underlying operating system fromthe upper-layer application software.

The middleware enhances the software portability among different platforms. The applicationsoftware can be used on different hardware platforms with minimal effort. Therefore, the systemcan provide the stable software version within a short time.

Application SoftwareThe application software is on the top layer in the software structure of the MSOFTX3000. Byloading different application software, boards can provide different functions and features. Theapplication software of the MSOFTX3000 can be classified into the following types:

l Signaling bearer software: The software is distributed on the WBSG and the WIFM. Itfulfills functions such as broadband and narrowband signaling access and lower-layerprotocol processing.

l Service processing software: The software is distributed on the WCCU and WMGC. Itfulfills functions such as call signaling processing, mobility management, and resourcemanagement.

l Database software: The software is distributed on the WCDB and WVDB. It manages thedata of the MSOFTX3000 and dynamic subscriber data.

l System support software: The software is distributed on the SMM and service boards. Itimplements system management and equipment communication.

l Operation and maintenance software: The software is distributed on the SMM and serviceboards. It receives instructions from the OMU and returns the results.

1.4.3 OMU SoftwareThe OMU software consists of the OMU, LMT, WebUI, and iGWB. The OMU is distributedon boards and the LMT is distributed on workstations. The OMU software fulfills functions suchas man-machine interaction and equipment management.

The OMU software is classified into the following types:



1-15

l OMU: The OMU software is the core of the operation, administration, and maintenancesystem. You can log in to the OMU through the LMT to maintain the equipment and manageuser rights.

l LMT: The LMT, also known as the client software, incorporates different service consoles.You can manage data, equipment, and alarms through the LMT.

l WebUI: The WebUI software, that is, the WEB client, enables you to perform performancemanagement and system upgrade through the WEB browser (Internet Explorer).

1.5 System ProcessThe system processes of the MSOFTX3000 can be classified into host process and OMU process.

1.5.1 Host ProcessThe host processes of the MSOFTX3000 consist of the following: MON, IMU, SRMU, SMU,and service processes.

1.5.2 Background ProcessThe background processes of the MSOFTX3000 consist of the following: O&M access process,service processing process, equipment access process, and resource monitoring process.

1.5.1 Host ProcessThe host processes of the MSOFTX3000 consist of the following: MON, IMU, SRMU, SMU,and service processes.

Figure 1-10 shows the deployment of the host processes.

Figure 1-10 Deployment of the host processes

MON

SMU

SMM

MON

SMU

SMMService processing board

IMU

MON

GCU100

SRMU

IMU

MON

GCU100

SRMU

IMU

MON

VCU100

IMU

MON

VCU100

……


System Principle


Issue 01 (2009-02-10)

l MON process (monitoring process): Each board runs one MON process. If a certain processon the board exits, the MON process starts the process automatically. In addition, the MONprocess detects the status of the other processes on the same board using heartbeat signals.If the MON process determines that a process is abnormal, then it restarts the process too.

l IMU process (board management process): Each service processing board runs an IMUprocess. The IMU process manages the board hardware resources. For example, the IMUprocess periodically checks the temperature and voltage of the CPU, status of the networkport, and time of the board.

l SRMU process (subrack management process): Each subrack runs two SRMU processes.The two processes are deployed on the boards where the active and the standby GCU100process groups reside. The SRMU arbitrates the status of the processes in the same subrackand reports the status of the processes to the SRMU processes in other subrack and the IMUprocess in the same subrack.

l SMU process (system management process): One SMM runs an SMU process. The SMUprocesses work in active/standby mode. They manage the status of the hardware in thesubrack and arbitrate the active/standby status of the SRMU processes in the same subrack.

l Service process: The service process, also known as service module, processes specificservices. The system has six types of service modules. They are WCCU, WVDB, WBSG,WIFM, WCDB, and WMGC. These processes are deployed on service processing boardsin three combination modes.– GCU100 process group: The GCU100 process group runs on the UPB. The

configuration of a GCU100 process group is as follows: 8CCU+2VDB+2BSG+1CDB+1IFM+1MGC.

– GCU101 process group: The GCU101 process group runs on the UPB. Theconfiguration of a GCU101 process group is as follows: 8CCU+2BSG+1CDB+1IFM+1MGC.

– VCU100 process group: The VCU100 process group runs on the UPB. Theconfiguration of a VCU100 process group is as follows: 10CCU+3VDB+3BSG.

– TCU100 process group: The TCU100 process group runs on the UPB. The configurationof a VCU100 process group is as follows: 12CCU+2BSG.

1.5.2 Background ProcessThe background processes of the MSOFTX3000 consist of the following: O&M access process,service processing process, equipment access process, and resource monitoring process.

Each module incorporates multiple background processes to implement the functions of a certainmanagement function domain. Figure 1-11 shows the logical view of the background processes.



1-17

Figure 1-11 Logical view of the background processes

O&Maccessprocess

Serviceprocessing

process

Equipmentaccessprocess

Active Mirror

OMU Monitor

Monitor thestatus of the

Mirror process

Standby Mirror

OMU Monitor

Dual-OMUcluster heartbeat

Resourcemonitoring

process

Active OMU Standby OMU

Monitor the service status

Monitor thestatus of the

Mirror process

l Resource monitoring process: The resource monitoring processes monitor the status of the

system service processes. This type of process consists of the OMUMonitor process andthe Mirror process. The OMUMonitor process monitors the Mirror process while the Mirrorprocess monitors the service processes except the OMUMonitor process. When theOMUMonitor process detects that the Mirror process exits, it starts the Mirror processautomatically. When the Mirror process detects that a certain background process exits, itrestarts the process automatically. In addition, in the dual-node configuration, the Mirrorprocess provides the dual-node status arbitration and switchover functions.

l O&M access process: The O&M access processes provide various O&M interfaces to helpyou maintain the system. They receive the messages sent from the upper-layer managementsystem and service processing processes, converts the format of the messages, and deliversthe messages. This type of process consists of MML, LMT-SRV, SOAP-AGT, and SNMP-AGT. They fulfill functions such as command parsing, command delivery, messagegeneration, operation authentication, and operation log.

l Equipment access process: The equipment access processes provide various equipmentaccess interfaces to help you maintain multiple types of equipment. They receive themessages sent from the service processing processes and the host, converts the format ofthe messages, and delivers the messages. This type of processes consists of the SNMP-MGR (SNMP Management) process and binary interface process. They provide the SNMPinterface and binary interface between NEs.

l Service processing process: The service processing processes manage thetelecommunications network. They receive the messages from the O&M access processesand equipment access processes. They fulfill functions such as configuration management,alarm management, maintenance, performance management, security management,inventory management, monitoring management, backup management, reportmanagement, and resource management.


System Principle


Issue 01 (2009-02-10)

2 Service Processing Subsystem

About This Chapter

This topic describes the service processing subsystem. The service processing subsystem is thecore of the MSOFTX3000. It implements functions with the assistance of the operation andmaintenance management subsystem and the environment monitoring subsystem.

2.1 Processing of Signaling over IPThis topic describes the processing of signaling over IP.

HUAWEI MSOFTX3000 Mobile SoftSwitch CenterSystem Principle 2 Service Processing Subsystem


2-1

2.1 Processing of Signaling over IPThis topic describes the processing of signaling over IP.

The MSOFTX3000 supports following types of signaling over IP:

l SS7 signaling over M2UA, including TUP, ISUP, SCCP, and upper-layer user protocols

l SS7 signaling over M3UA

l BICC signaling over SCTP

l SIP signaling over UDP

l H.248 signaling over SCTP

2.1.1 Processing of Signaling over M2UAThis topic describes the uplink processing path and the downlink processing path of signalingover M2UA.


2.1.3 Processing of Signaling over BICCThis topic describes the uplink processing path and the downlink processing path of signalingover BICC.

2.1.4 Processing of Signaling over SIPThis topic describes the uplink processing path and the downlink processing path of signalingover SIP.

2.1.5 Processing of Signaling over H.248This topic describes the uplink processing path and the downlink processing path of signalingover H.248.


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

2 Service Processing SubsystemHUAWEI MSOFTX3000 Mobile SoftSwitch Center

System Principle


Issue 01 (2009-02-10)

Figure 2-1 Uplink processing path of signaling over M2UA

SWI

SWU

UPB

IFM

MGC

CDB

USI

UPB

IFM

MGC

CDB

USI

UPB

BSG

VDB

CCU

UPB

BSG

VDB

CCU

UPB

BSG

VDB

CCU

UPB

BSG

VDB

CCU

SWI

SWU

Fabric 1

Fabric 2Fabric 1

Fabric 1Fabric 2

Fabric 2

SWI

SWU

SWI

SWU

Uplink Processing Path1. The USI board receives IP packets through the external IP interface, performs physical

layer processing of the messages, and transfers the packets to the IFM process through afixed connection.

2. After MAC layer processing of the messages, the IFM process, based on the IP protocoltype, local IP address, local SCTP port number, peer IP address, and peer SCTP portnumber, transfers the messages to the designated BSG process through the Ethernetswitching plane, i.e. the Fabric plane, for further processing. This process is called level-1message dispatch or bearer signaling message dispatch.

NOTE

You need to configure the mapping between BSG process and the combination of IP protocol type,local IP address, local SCTP port number, peer IP address, and peer SCTP port number.

3. After IP, SCTP, M2UA, and MTP3 layer processing of the messages, the BSG processtransfers the messages to the upper-layer dispatch modules, namely, TUP/ISUP and SCCP,for level-2 message dispatch.

4. The TUP/ISUP dispatch module, based on the NI, OPC, DPC, and CIC, transfers themessages through the Ethernet switching plane to the CCU process that is responsible forprocessing the CIC. The SCCP dispatch module transfers the messages to the CCU processthat is responsible for processing the session based on the TCAP session ID or to the CCUprocess with the least load.

5. The CCU process performs user layer processing of the messages.



2-3

Downlink Processing Path1. The CCU process, based on the module number of the BSG associated with M2UA and

MTP3 links, transfers the received messages through the Ethernet switching plane to thecorresponding BSG process.

2. After M2UA and MTP3 layer processing of the messages, the BSG process, based on thesource IP address of the IP packets, transfers the messages to the designated IFM processthrough the Ethernet switching plane.

3. After MAC layer processing of the messages, the IFM process transfers the IP messagesto the USI board through a fixed connection.

4. The USI board processes the IP messages, and sends them out of the MSOFTX3000 throughthe network cable.


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

Figure 2-2 Uplink processing path of signaling over M3UA

SWI

SWU

UPB

IFM

MGC

CDB

USI

UPB

IFM

MGC

CDB

USI

UPB

BSG

VDB

CCU

UPB

BSG

VDB

CCU

UPB

BSG

VDB

CCU

UPB

BSG

VDB

CCU

SWI

SWU

Fabric 1

Fabric 2Fabric 1

Fabric 1Fabric 2

Fabric 2

SWI

SWU

SWI

SWU


System Principle


Issue 01 (2009-02-10)




3. After IP, SCTP, and M3UA layer processing, the BSG process adapts the M3UA layer tothe MTP3 layer (with the embedded SG feature), and transfers the messages to the upper-layer dispatch modules, namely, TUP/ISUP and SCCP.

NOTE

The adaptation of M3UA to MTP3 shields M3UA for the upper layers so that the upper layers interactonly with the MTP3 layer.

4. The TUP/ISUP dispatch module, based on the NI, OPC, DPC, and CIC, transfers themessages through the Ethernet switching plane to the CCU process that is responsible forprocessing the CIC. The SCCP dispatch module transfers the messages to the CCU processthat is responsible for processing the session based on the TCAP session ID or to the CCUprocess with the least load.


Downlink Processing Path1. The CCU process, based on the module number of the BSG associated with M2UA and

MTP3 links, transfers the received messages through the Ethernet switching plane to thecorresponding BSG process.

2. After M3UA layer processing of the messages, the BSG process, based on the source IPaddress of the IP packets, transfers the messages to the designated IFM process throughthe Ethernet switching plane.

3. After MAC layer processing of the messages, the IFM process transfers the IP messagesto the USI board through a fixed connection.


2.1.3 Processing of Signaling over BICCThis topic describes the uplink processing path and the downlink processing path of signalingover BICC.

The BICC protocol is used on the Nc interface. Figure 2-3 shows the processing paths ofsignaling over BICC in the MSOFTX3000.



2-5

Figure 2-3 Uplink processing path of signaling over BICC

SWI

SWU

UPB

IFM

MGC

CDB

USI

UPB

IFM

MGC

CDB

USI

UPB

BSG

VDB

CCU

UPB

BSG

VDB

CCU

UPB

BSG

VDB

CCU

UPB

BSG

VDB

CCU

SWI

SWU

Fabric 1

Fabric 2Fabric 1

Fabric 1Fabric 2

Fabric 2

SWI

SWU

SWI

SWU

Uplink Processing Path1. The USI board receives IP messages through the external IP interface, performs physical

layer processing of the messages, and transfers the messages to the IFM process through afixed connection.


3. After the IP and SCTP layer processing of the messages, the BSG process, based on theoffice direction of the SCTP link and the CIC in the messages, forwards the messages tothe corresponding CCU process through the BICC agent module. The CCU can reside inthe same subrack as the BSG or in a different subrack, depending on the data configuration.


Downlink Processing Path1. The CCU process determines the office direction and generates BICC messages. The CCU

process then selects an active SCTP link with the least load, and sends the messages throughthe Ethernet switching plane to the BSG process associated with the SCTP link for furtherprocessing.

2. The BSG process, based on the source IP address of the IP packets, transfers the messagesto the designated IFM process through the Ethernet switching plane.


System Principle


Issue 01 (2009-02-10)

3. After MAC layer processing of the messages, the IFM process transfers the IP messagesto the USI through a fixed connection.


2.1.4 Processing of Signaling over SIPThis topic describes the uplink processing path and the downlink processing path of signalingover SIP.

The SIP protocol is used on the UDP port. Figure 2-4 shows the processing paths of signalingover SIP in the MSOFTX3000.

Figure 2-4 Uplink processing path of signaling over SIP

SWI

SWU

UPB

IFM

MGC

CDB

USI

UPB

IFM

MGC

CDB

USI

UPB

BSG

VDB

CCU

UPB

BSG

VDB

CCU

UPB

BSG

VDB

CCU

UPB

BSG

VDB

CCU

SWI

SWU

Fabric 1

Fabric 2Fabric 1

Fabric 1Fabric 2

Fabric 2

SWI

SWU

SWI

SWU



2. After MAC layer processing of the messages, the IFM process transfers the messagesthrough the Ethernet switching plane, i.e. the Fabric plane, to the corresponding BSGprocess for further processing. For the request messages, the IFM process selects the BSGprocess with the SIP processing capability and the least CPU usage. For the responsemessages, the the IFM process selects the BSG process based on the extended parameter



2-7

in the VIA header. This process is called level-1 message dispatch or bearer signalingmessage dispatch.

3. After processing the IP messages, the BSG process transfers the messages to the CCUprocess. For the initial request messages, the BSG process transfers the messages to theCCU process with the least load. For other messages, the BSG process transfers themessages to the same CCU process as the initial request messages. This process is calledlevel-2 message dispatch.

4. The CCU process performs connectin control of the IP messages.

Downlink Processing Path1. The CCU process generates SIP messages. For the response messages, the CCU process

transfers the messages to the BSG process that reports the corresponding request messages.For other messages, the process transfers the messages to the BSG process with the SIPprocessing capability and the least CPU usage.

2. After coding the SIP messages, the BSG process, based on the source IP address of the IPpackets, transfers the messages through the Ethernet switching plane to the target IFMprocess for further processing.



2.1.5 Processing of Signaling over H.248This topic describes the uplink processing path and the downlink processing path of signalingover H.248.

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


System Principle


Issue 01 (2009-02-10)

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

SWI

SWU

UPB

IFM

MGC

CDB

USI

IFM

MGC

CDB

USI

UPB

BSG

VDB

CCU

UPB

BSG

VDB

CCU

UPB

BSG

VDB

CCU

UPB

BSG

VDB

CCU

SWI

SWU

Fabric 1

Fabric 2Fabric 1

Fabric 1Fabric 2

Fabric 2

SWI

SWU

SWI

SWU

UPB



2. After MAC layer processing of the messages, the IFM process, based on the IP protocoltype, local IP address, local SCTP port number, peer IP address, and peer SCTP portnumber, transfers the messages to the designated BSG process through the Ethernetswitching plane for further processing.

3. After IP and SCTP layer processing of the messages, the BSG process transfers themessages to the H.248 dispatch module.

4. The H.248 dispatch module decodes the H.248 messages and transfers the messages to theCCU or MGC process.

5. The uplink H.248 messages consists of ServiceChange message, Notify messages, andresponse messages. For the ServiceChange messages (used for MGW registration, linkstatus maintenance, and TDM termination status maintenance), the BSG process transfersthe messages to the designated MGC process based on the MGC module number (thenumber should be configured manually). For the Notify messages (used for reporting H.248 events), the BSG process transfers the messages to the MGC or CCU process,depending on the type of the H.248 event. For the H.248 events irrelevant to calls or withall-zero or all-F Request ID, the BSG process transfers the messages to the MGC process.For other H.248 events, the BSG process transfers the messages to the CCU process. Forthe response messages, the BSG process transfers the messages to the MGC or CCU processbased on the Transaction ID in the H.248 messages. The Transaction ID in the H.248



2-9

messages is allocated by the MGC or CCU process when reporting request messages. Itcontains the module number of the MGC or the CCU process. Therefore, the BSG processcan obtain the corresponding module number through the Transaction ID carried in theresponse messages.

Downlink Processing Path1. The CCU or the MGC selects an appropriate SCTP link, and sends the H.248 messages to

the BSG module associated with the SCTP link. The CCU process initiates connectioncontrol messages while the MGC process initiates MGW management and resourcemanagement messages.

2. After the H.248 dispatch module of the BSG process decodes the H.248 messages, the BSGprocess, based on the source IP address of the IP packets, transfers the messages throughthe Ethernet switching plane to the target IFM process for further processing.




System Principle


Issue 01 (2009-02-10)

3 Maintenance Management Subsystem

About This Chapter

This chapter describes the maintenance and management subsystem in the MSOFTX3000.

3.1 Hardware ArchitectureThis section describes the hardware architecture of the maintenance and management subsystem.

3.2 Software ArchitectureThis topic describes the software architecture of the maintenance and management subsystem.The maintenance and management subsystem consists of the following software components:LMT software and OMU software, NMS software, and iGWB software.

3.3 Security ManagementThis section describes the security management functions of the MSOFTX3000.

3.4 Data ManagementThis section describes how to manage data in the MSOFTX3000, namely, how to store andoperate data. In terms of data storage, both OMU data and host data are involved.

3.5 Loading DataThis section describes how to load software and data from an external memory to the memoryof the board in the MSOFTX3000.

3.6 Software Patch ManagementThis section describes how to manage software patches.

HUAWEI MSOFTX3000 Mobile SoftSwitch CenterSystem Principle 3 Maintenance Management Subsystem


3-1

3.1 Hardware ArchitectureThis section describes the hardware architecture of the maintenance and management subsystem.

The maintenance management subsystem consists of the following hardware components:

l OMU

l iGWB

l LMT

Figure 3-1 shows the hardware architecture of the maintenance management subsystem.

Figure 3-1 Hardware architecture of the maintenance management subsystem

OMU

OMU

iGWB

iGWB

USI USI USI USI

SWU SWU

UPB

UPB

SWU SWU

To the billing center

IPMB plane

Farbic plane

Base plane

The MSOFTX3000 transmits maintenance and device management messages through the Baseplane (also called the management communication plane).

The management communication plane is used to transmit maintenance, backup, and devicemanagement messages. Take the message flows between the OMU and a service processingboard for example.

The message flow from the OMU to the service processing board is as follows:

3 Maintenance Management SubsystemHUAWEI MSOFTX3000 Mobile SoftSwitch Center

System Principle


Issue 01 (2009-02-10)

1. A maintenance engineer issues a management message through the LMT.2. The LMT sends this message to the OMU through the GE interface on the LAN switch.3. The OMU forwards this message to the service processing board through the intra- or inter-

subrack Base plane.

The message flow from the service processing board to the OMU is as follows:

1. The service processing board sends a management message to the OMU through the Baseplane.

2. The OMU processes this message, and then sends it to the LAN switch through the GEinterface.

3. The LAN switch forwards this message to the LMT and NMS.

3.1.1 OMUThis section describes the functions of the OMU.

3.1.2 iGWBThis topic describes the functions and specifications of the iGWB.

3.1.3 Local Maintenance Terminal (LMT)This section describes the functions of the LMT.

3.1.1 OMUThis section describes the functions of the OMU.

The Operation & Maintenance Unit (OMU) is a server board designed for operation andmaintenance purposes. It serves as a bridge between the MSOFTX3000 and the LMT. Uponreceiving an operation and maintenance command from a local or remote LMT, the OMU sendsthis command to the MSOFTX3000, Then, the MSOFTX3000 returns a response to the LMT.In addition, the OMU stores and transfers alarm information and performance measurementinformation.

NOTE

The OMU is a back administration module, whereas the host is a front administration module. In thisdocument, the host refers to the MSOFTX3000.

The OMU is installed on the UPB. It runs with the Linux operating system and the DB2 database.

3.1.2 iGWBThis topic describes the functions and specifications of the iGWB.

The iGWB is in active/standby mode. The functions and specifications of the iGWB are asfollows:

l The iGWB is a board seated in the basic subrack. If several pairs of iGWBs are present,plan the boards according to the actual requirements.

l The iGWB, located between the MSOFTX3000 and the billing center, provides thefollowing functions: receiving CDRs, preprocessing CDRs, storing CDRs, and serving asa billing interface.

l The iGWB communicates with the CCU through the internal communication system of theATCA by using the Huawei sliding window protocol. The iGWB communicates with thebilling center through the WAN/LAN by using the FTP/FTAM.



3-3

l The iGWB is equipped with the Windows Server 2003 operating system.

l In standard configuration, each pair of the iGWBs can process up to 3000 CDRs per second,and store original and final CDRs for at least 7 days.

l For more information, refer to the HUAWEI iGateway Bill User Manual.

3.1.3 Local Maintenance Terminal (LMT)This section describes the functions of the LMT.

The LMT provides the following functions:

l Data configuration

l Device status monitoring

l Maintenance

The LMT runs Windows XP operating system. It can be connected to the OMU through a webbrowser for performance management purposes.

3.2 Software ArchitectureThis topic describes the software architecture of the maintenance and management subsystem.The maintenance and management subsystem consists of the following software components:LMT software and OMU software, NMS software, and iGWB software.

Figure 3-2 shows the software architecture of the MSOFTX3000 maintenance and managementsubsystem.

Figure 3-2 Software architecture

iGWB software

OMU softwareHost

software

iGWB

Maintenance management subsystem

Local MaintenanceTerminal

EMS software

Billing center

NMS softwareElement management

system


System Principle


Issue 01 (2009-02-10)

NOTE

l For details on the working principles of the iGWB software, refer to the HUAWEI iGateway Bill UserManual.

l For details on the working principles of the EMS software, refer to the appropriate user manual.

l The OMU and iGWB communicate with the host for operation and maintenance, and CDRmanagement.

l The OMU software communicates with the EMS software by using the Man MachineLanguage (MML), Simple Object Access Protocol (SOAP), Simple Network ManagementProtocol (SNMP) for unified maintenance and management of the MSOFTX3000. TheNMS provides an access interface to connect the upper-layer network management system.

l The OMU communicates with the LMT through an Ethernet interface by using the TCP/IP.

3.2.1 OMU SoftwareThis section describes the functions, networking mode, components, and features of the OMUsoftware.

3.2.2 LMT SoftwareThis section describes the functions of the LMT software.

3.2.1 OMU SoftwareThis section describes the functions, networking mode, components, and features of the OMUsoftware.

The MSOFTX3000 provides a set of effective O&M options and tools to ensure servicecontinuity, slash operating costs, and improve QoS. The OMU software is primarily used formanagement and maintenance purposes. For instance, the OMU software can be used to managesystem data, performance management data (also called traffic statistics), and alarm information.

Networking ModeThe OMU, the center of the LMT, functions as the server using TCP/IP. On the one hand, theOMU responds to connection requests sent from the LMT for connection setup purposes byanalyzing and processing commands. On the other hand, the OMU responds to connectionrequests sent from the devices for connection setup purposes by processing data loading requestsand alarm information. Figure 3-3 shows the networking mode of the OMU.



3-5

Figure 3-3 Networking mode of the OMU

Local maintenance terminal

LAN switch

Active OMU Standby OMU

Host process

Heartbeat

Floating IP address (Base plane)

Floating IP address (Base plane)

NOTE

If the active and standby OMUs use individual IP addresses, it is inconvenient for active/standbyswitchover. To address this problem, a floating IP address is assigned for the active and standby OMUs tocommunicate with an external device.

ComponentsFigure 3-4 shows the components of the OMU software.


System Principle


Issue 01 (2009-02-10)

Figure 3-4 Components of the OMU software

DCM

LOAD

SNMP-MGR

CM

FM

DEBLOG

MM

PM

TM

RMM

RSM

SNMP-AGT

LMT-SRV

MML-SRV

SOAP

Deviceaccess North access

Service layer

Service layer

Communication layer

Navigation tree

Service

MML commands

Alarm information

Device management

Tracer

Task wizard

GUI operation

LMT architecture

LEM LMT

The OMU software consists of the following components:

l Configuration Management (CM): The CM is primarily used for data conversion. Itconverts the data in the OMU database into binary data, and then sends binary data to thehost based on online settings.

l Fault Management (FM): The system reports events, faults, and fault recoveries to the OMUor EMS. The FM provides hierarchical fault management for pinpointing and eliminatingfaults in time.

l Device log (DEVLOG): The DEVLOG reports software running information in text formatto the OMU and LMT. It provides significant information for system maintenance.

l Maintenance Management (MM): The MM maintains and detects system running status intime.

l North Interface (NI): The NI is used to access the system through the SOAP, SNMP agent,MML server, and LMT server.

l SNMP Management (SNMP-MGR): The SNMP-MGR is a network protocol managementmodule on the MSOFTX3000 side. It provides an interface through the SNMP agent.

l Performance Management (PM): The PM collects and displays performance measurementdata. It is an important maintenance option.

l Device Communication Management (DCM): The DCM manages and monitorscommunication links on the MSOFTX3000 side, and exchanges messages between theOMU and other devices.



3-7

l LOAD: The LOAD is used to load host programs and data files.

l Trace Management (TM): The TM provides an interface for tracing service messages.

l Management Information Tree (MIT): The MIT is used to query managed devices, andsubscribe to and release notifications of managed devices.

l Real-time Monitor Management (RMM): The RMM is used to monitor and managementtasks, query status information, and send status information to the LMT.

l Report Server Management (RSM): The RSM is used to resolve and report performancereports.

Features

The OMU software provides the following features:

l High availabilityThe OMU uses a carrier-class server and a DB2 as a large database system. The active/standby OMU provides multi-level self-monitoring options to facilitate data backup, datarecovery, and data security.

l Client/server (C/S) modeBy integrating the communication server with the database server, the OMU performsmaintenance tasks in C/S mode, supports simultaneous local or remote data configuration,and ensures ease of operation and maintenance.

l User friendly interfacesThe OMU provides the following user friendly interfaces:– The MML command line interface is used for data configuration and O&M purposes

in the CGP system.– Graphical User Interface (GUI) helps visibly manage alarm information, trace messages

over interfaces, and observe running status.– Web User Interface (WebUI) is used to achieve performance management.

l ScalabilityThe OMU provides high scalability through the following ways:– Managing multiple network elements in distributed mode

– Providing superior performance

– Supporting inter-operation-system or inter-database transplanting

– Providing object-specific operations

– Supporting various standard interfaces such as SNMP

3.2.2 LMT SoftwareThis section describes the functions of the LMT software.

The O&M software of the MSOFTX3000 can be installed on a local or remote LMT. The LMTcan communicate with the OMU through a WAN/LAN. The LMT and the OMU work in C/Smode. The LMT, serving as the client, provides a user-oriented O&M interface.

The LMT software provides the following O&M options through MML and GUI:

l Service management system


System Principle


Issue 01 (2009-02-10)

l Alarm management system

l Performance management system

Service Management System

The LMT software provides the following GUI-enabled modules:

l Object navigation tree

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

l MML navigation tree

The MML navigation tree provides basic command groups that are sorted by attribute. Youcan identify the desired MML command by expanding the MML command tree, and thendouble-click the MML command to display the command input pane and Help informationpane.

When you type commands and parameters, the LMT automatically issues the commandsfor the following purposes:

– Data configuration

– Alarm management

– Subscriber management

l Tracing management

Tracing management provides the following functions for fault location and analysis:connection tracing, signaling tracing, interface tracing, and message interpretation. Youcan use them to trace terminals, trunk circuits, signaling links, and interface protocols ona real-time and dynamic basis in terms of: connection process, status transition, resourceutilization, telephone number information transfer, and message streams. The tracinginformation can be stored for future reference.

l Monitoring management

Monitoring management can be used to dynamically display the following information:

– Board-specific CPU usage

– Memory usage

– Memory dumping

– Memory contents

– Process running status of the OMU and the host

l Front panel

The front panel provides the following functions:

– Device management

– Loading status management

NOTEDevice management is commonly used during routine maintenance. Using this function, you need notdirectly observe the device, but observe the GUI to know system running status and board running status.



3-9

Alarm Management SystemThe alarm management system provides clear and concise alarms on a real-time basis. You canquery, browse, and manage alarms through the LMT.

An alarm includes the following information:

l Alarm name

l Alarm generation time and fault recovery time

l Alarm level

l Fault location information

l Fault recovery suggestions

Performance Measurement SystemPerformance measurement (also known as traffic measurement) is used to measure call-specificservices and objects. The performance management system provides the following functions:

l Showing the running status of the MSOFTX3000, MGW, MS, or PLMN

l Providing useful data for telecommunications network planning, design, implementation,management, and maintenance purposes

3.3 Security ManagementThis section describes the security management functions of the MSOFTX3000.

To access the MSOFTX3000, users must have privileges. To run MML commands on theMSOFTX3000, you must have both operator and workstation privileges.

3.3.1 Command GroupsThis section describes security management for command groups.

3.3.2 Workstation ManagementThis section describes security management for workstations.

3.3.3 Account ManagementThis section describes how to manage accounts.

3.3.4 Login TimeThis section describes how to use login time for security management.

3.3.5 Lock TimeThis section describes how to use lock time for security management.

3.3.1 Command GroupsThis section describes security management for command groups.

A specific privilege must be defined for each command group. A command can belong to oneor multiple command groups. When having been granted the privilege to use a command group,an operator or workstation can issue any command in this command group.

Default command groups are designed for different network elements. By default, theMSOFTX3000 provides 11 command groups, numbered from G_1 to G_11. Each command


System Principle


Issue 01 (2009-02-10)

group has a default command. Users are allowed to create command groups by adding commandsas required.

G_1 defines the administrator privilege for a command group. An administrator is allowed torun, add, and remove all commands in a command group.

3.3.2 Workstation ManagementThis section describes security management for workstations.

A workstation is a computer used for operators to issue commands. A user can use the AccessControl List (ACL) function to configure an IP address or a number segment for a workstationto access the OMU.

3.3.3 Account ManagementThis section describes how to manage accounts.

On the LMT of the MSOFTX3000, a user name is used to identify a unique operator. A newaccount can have the same user name and attributes as those of the deleted account. Theprivileges of the deleted account, however, are not transferred to the new account. This canprevent an invalid account or a deleted account from logging in to the system.

The password of an account is encrypted, and then stored in the database. To prevent thepassword against malicious attacks, the security mechanism of the database is integrated withthe encryption algorithm on the MSOFTX3000.

3.3.4 Login TimeThis section describes how to use login time for security management.

On the MSOFTX3000, the OMU allows an operator to log in to the system during a specifiedperiod of time. When logging in to the system within the specified period of time, the operatoris allowed to run authorized commands in a command group.

3.3.5 Lock TimeThis section describes how to use lock time for security management.

If a user does not perform any operation within a specified period of time, the user isautomatically locked out of the system. To relog in to the system, the user need to retype thepassword to unlock the system. This can prevent unwanted or unauthorized operations, andfurther ensures enforcement of assigned policies and system security.

You can configure the lock time on the LMT. The default value is three minutes.

3.4 Data ManagementThis section describes how to manage data in the MSOFTX3000, namely, how to store andoperate data. In terms of data storage, both OMU data and host data are involved.

3.4.1 Storing OMU DataOMU data is stored in the DB2. The security management module of the OMU enables operatorsto define access control levels for storing OMU data.

3.4.2 Storing Host Data



3-11

Host data is stored in the disk.

3.4.3 Operating DataThis topic describes how to operate data.

3.4.1 Storing OMU DataOMU data is stored in the DB2. The security management module of the OMU enables operatorsto define access control levels for storing OMU data.

OMU data is automatically backed up at a preset time. Before modifying any vital data, youmust manually back it up.

3.4.2 Storing Host DataHost data is stored in the disk.

After successfully loading data, a software management module automatically backs up the datato the disk of the board.

When the OMU performs data operations, the data management module associated with theactive and standby processes concurrently updates the memory database and backs up static datato the flash memory of the boards to which the active and standby processes belong.

3.4.3 Operating DataThis topic describes how to operate data.

If you have operated data on a workstation, the system performs the following steps: The servicessuch as the MML service on the OMU analyze the commands. The configuration managementservice stores the modified data in the database of the OMU and converts the data. The DCMservice on the OMU sends the converted data to the data management system of the host. Thedata management system updates the data on each service module for security purposes. Thename of a data file sent to the host contains DB_?.DAT, in which the question mark (?) denotesa module number. Data files vary depending on service processing modules.

Converting Data FormatThe OMU converts the data suitable for the LMT into that suitable for service processingmodules. You can convert all or part of the data as required. Only converted data, however, canbe loaded to service processing modules. Data format conversion needs to be performed in thefollowing scenarios:

l A new data file is forcibly regenerated.

l When you add, remove, or modify any data, the data management console automaticallyruns the FMT command to update the data file.

l When receiving the FMT command from the traffic statistics console, the OMU convertsthe data, and then writes the converted data to the data file in the appropriate module.

Configuring DataWhen you configure data, the OMU sends the converted data to the appropriate module in thehost.

After the data in the OMU is modified, you need to configure the data. When to configure thedata depends on whether the OMU is connected to the host and whether the format conversion


System Principle


Issue 01 (2009-02-10)

function is enabled. When the OMU is connected to the host, the data in the OMU isautomatically configured immediately after being modified. When the OMU is disconnectedfrom the host, the data in the OMU is not automatically configured immediately after beingmodified, but after the OMU is reconnected to the host. Data configuration is performed in thefollowing scenarios:

l After you run an ADD, RMV, or MOD command, the OMU automatically configure thedata.

l A forced operation is performed by issuing the FMT command.

Performing CRC CheckThe OMU of the CGP performs the Cyclic Redundancy Check (CRC) to check data consistencybetween the OMU and the host.

The OMU provides the MML command for CRC and periodically sends CRC requests to thehost for table-based data consistency check. When finding any inconsistent data, the OMUproactively sends a data setting request to the host. If this data inconsistency problem cannot beeliminated within preset times, the OMU automatically generates an alarm. To address thisproblem, you need to configure or load data to ensure data consistency.

Backing Up DataTo ensure data security, the system backs up the OMU and configuration files to a specifieddirectory. If the system experiences a fault, you can restore the data based on the database andconfiguration files. You can choose one of the following methods to back up data:

l Automatic backupYou can back up data during off-peak hours. When processing this backup command, thesystem does not accept any service command request.

l Manual backupYou can manually back up data by running an MML command or using the databasemanagement tool.

Performing Automatic Data Format Conversion During OMU RebootWhen the OMU is powered off exceptionally because the power supply becomes faulty, dataconversion or data formation may be unfinished. When the OMU is rebooted, the system checksfor unfinished tasks. If any unfinished task is identified, the system automatically resumes thetask.

Restoring DataTo ensure data security and system maintainability, the MSOFTX3000 provides a configurationrollback function to restore the data.

This function enables you to send critical service data to the host for trial operation so as to checkwhether any error is present.

l If the trial operation is successful and no error is found, you can make these experimentaldata take effect immediately.

l If any error is found, you can use the configuration rollback function to restore the data tothe original state securely and rapidly.



3-13

When you run the ADD, RMV, or MOD command to configure or modify data, the data isstored in the database first, then sent to the host, and finally validated in the host. If you haveperformed an incorrect operation, you need to restore the data settings by restoring the originaldatabase or rerunning the commands one by one. This is inconvenient for bulk operations.Restoring the original database involves table settings, host reset, and service interruption thatannoys carriers.

To address these problems, the MSOFTX3000 provides the configuration rollback function. Byusing this function, you can restore data as follows: 1. Run BGN TRAN to enable the networkelement to enter the transaction mode. 2. Run ADD, RMV, or MOD to change data. 3. RunCMT TRAN to enable the network element to enter the trial operation mode. 4. If any dataneeds to be restored, you can run RBK TST to return to the transaction mode and restore thedata. If any added, removed, or modified data needs to be confirmed, you can run CFM TST toconfirm the data. 5. If you need to cancel or stop the trial operation, you can run CNL TST orSTP TST to enable the network element to enter the normal operation mode.

When a user is restoring data settings for a certain network element, the system prevents anyother user from executing any command, such as a configuration or restoration command.

3.5 Loading DataThis section describes how to load software and data from an external memory to the memoryof the board in the MSOFTX3000.

3.5.1 Loading OptionsThis section describes the options for loading data, depending on file types and storage locations.3.5.2 Principles for Loading DataThis section describes the principles for loading data from the OMU.3.5.3 Procedure for Loading DataThis section describes the procedure for loading data from the OMU.

3.5.1 Loading OptionsThis section describes the options for loading data, depending on file types and storage locations.

Figure 3-5 shows the options for loading data.

Figure 3-5 Options for loading data

MemoryLocal

storagemedia

Write

Read

Data bus

Host board

OMULoad

BASE bus


System Principle


Issue 01 (2009-02-10)

Depending on different storage locations, the system loads data in the following ways:

l The system loads software and data from the local storage media (for example, hard disk)of the OMU or INU (INU for the operating system) to the memory of the board. In thiscase, all original files to be loaded are stored in the local storage media of the OMU or INU.

l The system loads software and data from the local storage media of a board to the memoryof the board. In this case, all original files to be loaded are stored in the local storage mediaof the board.

The system loads the following types of files:

l Operating system file: The system loads operating system files from the local storage mediaof a board or a network to the memory.

l Host application file: The system loads service applications from the local storage mediaof a board to the memory, or downloads service applications to the local storage media andthen to the memory.

3.5.2 Principles for Loading DataThis section describes the principles for loading data from the OMU.

The MSOFTX3000 can load data from either the OMU or the local storage media of a board.Take the OMU for example. Figure 3-6 shows the connections for loading data.

Figure 3-6 Connections for loading data

OMU Hostboard

SWU

SWU

Base bus Base bus

Base bus Base bus

In the host, a board sends a data loading request to the SWU and OMU through two Base planes.If one Base plane becomes faulty, the remaining Base plane takes over.



3-15

3.5.3 Procedure for Loading DataThis section describes the procedure for loading data from the OMU.

Figure 3-7 shows the procedure for loading data.

Figure 3-7 Procedure for loading data

OMU

BIOS

NBPLBP

Starter

Applications and data files

OS (Linux)

The procedure for loading data is as follows:

1. When powering on or resetting the subrack, each board automatically runs its own BIOSapplication.

2. Based on the boot option, the BIOS application determines whether to boot the operatingsystem locally or through the network.

l If the BIOS application determines to boot the operating system locally, the operatingsystem checks whether local boot attempts fail more than three times.

– If yes, the operating system is booted through the network and then automaticallyrestored.

– If no, the operating system is loaded from the local storage media and then booted.

l If the BIOS application determines to boot the operating system through the network,the operating system is booted based on the PXE as follows:

– The operating system loads a network boot program (NBP) from the OMU, and thenruns it.

– This NBP reads the subrack number, slot number, and hardware version through thehardware interface, and then sends a loading request to the OMU.


System Principle


Issue 01 (2009-02-10)

– The OMU reads the configuration data based on the subrack number, slot number,and hardware version, and then sends the operating system file to the NBP usingTFTP.

– Upon receiving the operating system file, the NBP boots the operating system.

3. After the operating system is booted, a platform management application is automaticallystarted.

4. If any local storage media or file is present, this application reports application and datafiles in the local storage media to the OMU for CRC purposes.

5. If no local storage media or file is present, this application reports a null CRC value to theOMU. Then, the OMU performs CRC for checking file consistency between the localstorage media and the host.l If any inconsistent file is detected, the OMU requests the host to load the file to the local

storage media.l If no local storage media is detected, the OMU requests the host to load the file to the

memory.6. When the file is successfully loaded, the operating system runs its applications.

3.6 Software Patch ManagementThis section describes how to manage software patches.

During system runnings, adaptive or corrective modifications probably need to be made to thehost software. For example, you may need to correct potential defects in the system or add newfunctions to meet service requirements. To address these needs, the traditional solution is to stopand upgrade the host software. This traditional solution not only causes service interruption butalso deteriorates QoS. Now, Huawei provides the latest solution to dynamically upgrade the hostsoftware using patches. This not only avoids service interruption or minimizes the impact onservices, but also improves QoS.

3.6.1 Basic ConceptsThis section describes basic concepts related to software patches.

3.6.2 Key FeaturesThis section describes the key features of a software patch.

3.6.3 ArchitectureThis section describes the architecture of a patch.

3.6.4 ImplementationThis topic describes how to install and uninstall a patch, patch states, and patch state transition.

3.6.1 Basic ConceptsThis section describes basic concepts related to software patches.

PatchA patch is an executable program used to fix a problem with or update a host software.



3-17

Patch Number

Patches are developed to fix problems identified during system running. These patches arenumbered in time sequence, for example, patch 1# and patch 2#.

Patch Area

The host memory reserves some space for storing patches.

General-Purpose Patch

A general-purpose patch is used to fix a common problem (for example, a bug) in a main version.

Special-Purpose Patch

A special-purpose patch is used to fix a rare problem (for example, multi-vendor interoperability)in a few offices.

Patch File

A patch file is a update file used to fix a problem in a main version.

Cold Patch

A cold patch is used to fix a defect by adding a new file or overwriting the source file with anew file. When installing a cold patch, you need to interrupt the service and reboot the system.Every cold patch can be installed, moved, or queried for repairing or maintenance purposes.

Hot Patch

A hot patch is used to fix a defect by replacing source codes with new codes. When installing ahot patch, you need not to interrupt any service and restart the system.

3.6.2 Key FeaturesThis section describes the key features of a software patch.

Main Version-Specific

A patch is designed for a specific main version. If a patch is used for main version A, it cannotbe used for main version B. The reverse is true as well.

If the number of patches reach the limit, the main version need to be upgraded. Existing patchesare packaged in new patches to be released.

Service Packs

A service pack comprises one or multiple cold/hot patches specific to a main version. A servicepack need to be formally released by following the version release procedure. Hot patches arepackaged in a service pack, whereas cold patches are packaged in another service pack. Do notpackage both hot and cold patches in a service pack.


System Principle


Issue 01 (2009-02-10)

Ease of InstallationA hot patch is easy to install with several MML commands available for maintenance personnel.When installing a hot patch, you need not to restart the system.

CAUTIONPatch installation has a direct impact on CPU; therefore, only users who have administratorprivileges are allowed to install patches.

Self-HealingIf the system is restarted when experiencing a fault, the patches will be automatically loaded tothe boards.

3.6.3 ArchitectureThis section describes the architecture of a patch.

Patch ToolA patch consists of the following components:

l Patch tool

l OMU patch management module

l Host patch management module

A patch tool is used to generate a patch file in offline mode by using one or multiple patches.

OMU Patch Management ModuleThe OMU patch management module is part of the OMU software. It provides the followingfunctions:

l Providing a command interface for maintenance purposes

l Maintaining data consistency between the patch configuration/status tables and the hostbased on the command information in the host

l Transferring patch files to the host

l Generating patch reports

Host Patch Management ModuleThe host patch management module is part of the host software. It provides the followingfunctions:

l Processing patch-specific commands and maintaining the interface

l Maintaining data consistency between the patch status table and the host based on thecommand information

l Receiving patch files and transferring patches to the patch area in the host



3-19

l Writing patch files to the flash memory

l Restoring patches after system reboot

l Synchronizing patches between the OMU and the host

3.6.4 ImplementationThis topic describes how to install and uninstall a patch, patch states, and patch state transition.

l Installing and uninstalling a patchTo install a hot patch, perform the following steps: Copy a hot patch or service pack fromthe LMT to the Upload folder using the FTP. Run LOD PKG to decompress the hot patchor service pack and copy it to the patch area. You can install or uninstall the patch whenthe equipment is running by loading, activating, rolling back, running, removing, orquerying the hot patch or service pack. You can also uninstall a hot patch by running ULODPKG.To install a cold patch, perform the following steps: Copy a service pack from the LMT tothe Upload folder using the FTP. Run LOD PKG to decompress the service pack and copyit to the patch area. You can install or uninstall the patch by loading, activating, deactivating,rolling back, or querying the service pack. You can also uninstall a cold patch by runningULOD PKG.

l Patch statesThe host software displays the following patch states for hot patches:– Idle: No hot patch is present.

– Deactive: The hot patch is installed in the patch area, but not activated. In this case, thecodes cannot be executed.

– Active: The hot patch is activated for trial running. In this case, the codes can beexecuted.

– Running: The hot patch is running. In this case, you cannot roll back the patch, butremove the patch.

The host software displays the following patch states for cold patches:– Deactive: The host and OMU return to the state before the loading of the cold patch.

– Updated: The contents of the cold patch are updated on the OMU.

– Active: The contents of the cold patch are updated on the host.

– Rollback: The OMU returns to the state before the loading of the cold patch.

Figure 3-8 shows how a hot patch transits from one state to another.


System Principle


Issue 01 (2009-02-10)

Figure 3-8 State transition of hot patches

Idle

Running

Deactivated

ActivatedConfirm

System reset

Active

Deactive

System reset

Remove

Remove

Load

Remove

System reset

System reset

The active state is temporary. If the system is properly running for a short period of time, youcan run CON PATCH to transit the patch from the active state to the running state. If you identifya defect, you can run DEA PATCH to roll back this patch and transit it from the active state tothe deactive state.

The running state is a steady state. When the system is restarted, only the patches in the runningstate are loaded to the system. The patches in the active state are not loaded to the system.

When the system does not require a patch, you can run RMV PATCH to remove it. In this case,this patch enters the idle state.



3-21

4 Environment Monitoring Subsystem

About This Chapter

This chapter describes the environment monitoring subsystem. The environment monitoringsubsystem monitors and adjusts the power supply, fan, and equipment room to enable theMSOFTX3000 to work in a proper environment.

4.1 Power SupplyThe power supply is a vital part of the MSOFTX3000. To ensure high reliability, theMSOFTX3000 provides dual 3-input power supplies. These power supplies are self-monitoring.A power supply consists of a power input unit and a power distribution unit.

4.2 Monitoring Power SuppliesThe MSOFTX3000 provides a power monitoring module to monitor power supplies, reportpower status, and generate alarms on a real-time basis. The power monitoring module is housedin the PDF.

4.3 Monitoring Fan BoxesThe MSOFTX3000 provides integrated service processing subracks with built-in fan boxes. Afan monitoring module is used to monitor fan status and to increase/decrease rotation speedsbased on temperature readings.

4.4 Monitoring the Environment of a Telecommunications RoomThis topic describes how to monitor the environment of a telecommunications room. The PDFand MRMU are used to monitor the environment of a telecommunications room. Monitoringthe environment of a telecommunications room is an optional function.

HUAWEI MSOFTX3000 Mobile SoftSwitch CenterSystem Principle 4 Environment Monitoring Subsystem


4-1

4.1 Power SupplyThe power supply is a vital part of the MSOFTX3000. To ensure high reliability, theMSOFTX3000 provides dual 3-input power supplies. These power supplies are self-monitoring.A power supply consists of a power input unit and a power distribution unit.

4.1.1 Power Input UnitA power input unit is used to power the MSOFTX3000 cabinet using the Power DistributionFrame (PDF).

4.1.2 Power Distribution UnitA power distribution unit is designed to distribute power from the PDF to individual cabinetcomponents.

4.1.1 Power Input UnitA power input unit is used to power the MSOFTX3000 cabinet using the Power DistributionFrame (PDF).

Figure 4-1 shows the power input unit.

Figure 4-1 Power input unit

-48V1

-48V2

GND

GND

PGND

(4)

(1)

(2)

(3) (3) (3)

RTN_A1

RTN_A2

RTN_A3NEG_A3

NEG_A2

NEG_A1RTN_B2NEG_B1RTN_B1

RTN_B3NEG_B3

NEG_B2

RTN_A1

RTN_A2

RTN_A3NEG_A3

NEG_A2


RTN_B3NEG_B3

NEG_B2

RTN_A1

RTN_A2

RTN_A3NEG_A3

NEG_A2


RTN_B3NEG_B3

NEG_B2

(1) DC distributor (2) PDF(3) MSOFTX3000 cabinet (4) Protection grounding bar

A power input unit consists of a DC distributor, a PDF, and power cables.

The DC power distribution cabinet and its upper-layer DC switchboard are not part of theMSOFTX3000. The DC power distribution cabinet is required to provide dual 3-input powersupplies with steady-state voltage.

During normal operation, dual power supplies simultaneously provide system power. When onepower supply becomes faulty, the remaining power supply immediately ramps up to provide fullpower and maintain uninterrupted power to the system.

4 Environment Monitoring SubsystemHUAWEI MSOFTX3000 Mobile SoftSwitch Center

System Principle


Issue 01 (2009-02-10)

4.1.2 Power Distribution UnitA power distribution unit is designed to distribute power from the PDF to individual cabinetcomponents.

Electrical ConnectionsThe MSOFTX3000 consists of integrated configuration cabinets and service processingcabinets. Different cabinets are equipped with different components. Their electrical connectionsvary from cabinet to cabinet, as shown in Figure 4-2.

Figure 4-2 Electrical connections

F

Service processing cabinet

AB 110 9 8 7 6 5 4 3 2 110 9 8 7 6 5 4 3 2RTN(+)NEG(-)

10+

10-

9+

9-

6+

6-

5+

5-

2+

2-

1+

1-

12+

12-

11+

11-

8+

8-

7+

7-

4+

4-

3+

3-

3-

Filler panel

Subrack 2

Subrack 1

Subrack 0

W1

W2

W3

W4

7-- + - +

5- 5+ 6- 6+- + - +

7+ 8- 8+

1- 2-- + - +

1+ 2+ 4-- + - +

3+ 4+

RTN(+)NEG(-)

9- 11-- + - + - + - +

9+ 11+ 12- 12+10- 10+

Filler panel

Integrated configuration cabinet

RTN(+)NEG(-)

Subrack 1

MRMU9 10

12

11

13

LAN switch 1

LAN switch 0

KVMS

Cabling space

Cabling space

Subrack 0

Filler panel

Filler panel

W2

W3

W4

W5

W6

W7

AB 110 9 8 7 6 5 4 3 2 110 9 8 7 6 5 4 3 2RTN(+)NEG(-)

5+

5-

6+

6-

1+

1-

2+

2-

19+

18-

17+

16-

15+

14-

12+

12-

9+

9-

7+

7-

8+

8-

3+

3-

4+

4-

19+

19-

17+

17-

15+

15-

11+10+

10-11-

13+

13-W1

- + - +5- 5+ 6- 6+

- + - +7+ 8- 8+

1- 2-- + - +

1+ 2+ 4-- + - +

3+ 4+



4-3

CAUTIONTable 4-1 lists the mappings between the cabinet components and the switches. Actual mappingsbetween cabinet components and switches differ. The mappings between the cabinet componentsand the switches in this table are used for example purposes only.

Table 4-1 Mappings between the cabinet components and the switches

Cabinet Switch Cabinet Component Air CircuitBreaker (PCS)

Integragedconfigurationcabinet

(A7), A8,(B7), and B8

SUBRACK-1 32A (4 PCS)

A2 and B2 MRMU 5A (2 PCS)

A3 LANS-1 5A (1 PC)

B3 LANS-0 5A (1 PC)

A1 KVMS 5A (1 PC)

A9, A10, B9,and B10


Serviceprocessingcabinet

A5, A6, B5,and B6


(A7), A8,(B7), and B8


A9, A10, B9,and B10


4.2 Monitoring Power SuppliesThe MSOFTX3000 provides a power monitoring module to monitor power supplies, reportpower status, and generate alarms on a real-time basis. The power monitoring module is housedin the PDF.

Each cabinet is equipped with a PDF that is monitored by subrack 0 in the MSOFTX3000.Figure 4-3 shows the connections for monitoring power supplies.


System Principle


Issue 01 (2009-02-10)

Figure 4-3 Connections for monitoring power supplies

OMU

Power monitoring board

SDM SDM

SMM SMM

RS 485 RS 485

OSTA 2.0 subrack

BASE bus

Power distribution frame (PDF)

The principles for monitoring power supplies are as follows:

l In the PDF, a power monitoring board is designed to report power status.l The power monitoring board provides two RS 485 serial ports (active/standby) to connect

two external cables. The two external cables are connected to the COM2 ports on the SDMsthat are the back boards of the active and standby SMMs.

l The SMM can process the information collected by the power monitoring board, and thenreport the information to the OMU. The OMU transfers the information to the OMC. Ifthere is any fault, the OMC generates an alarm and sends it to the alarm box or subsystem.

A cabinet is usually equipped with multiple service processing subracks. The service processingsubrack, which is installed in the lowest part of the cabinet, monitors the PDF.

4.3 Monitoring Fan BoxesThe MSOFTX3000 provides integrated service processing subracks with built-in fan boxes. Afan monitoring module is used to monitor fan status and to increase/decrease rotation speedsbased on temperature readings.

The SMM manages and monitors fan boxes through the IPMB bus.

Figure 4-4 shows how the SMM monitors fan boxes.



4-5

Figure 4-4 Monitoring fax boxes in an OSTA 2.0 subrack

FAN

SMM SMM

FAN

IPMB

A fan box communicates with the SMM through the BMC. A fan box also reports an alarmthrough the BMC. The BMC can increase or decrease rotation speeds as requested by the SMM.

4.4 Monitoring the Environment of a TelecommunicationsRoom

This topic describes how to monitor the environment of a telecommunications room. The PDFand MRMU are used to monitor the environment of a telecommunications room. Monitoringthe environment of a telecommunications room is an optional function.

Figure 4-5 shows the structure of the monitoring system.

Figure 4-5 Structure of the monitoring system

OMU

Power monitoring board

SDM SDM

SMM SMM

RS 485 RS 485

OSTA 2.0 subrack

BASE bus

Power distribution frame (PDF)Booleansensor


System Principle


Issue 01 (2009-02-10)

The PDF provides four external Boolean detection interfaces that are used to connect access,water, smoke, and other sensors for information collection purposes. The way of reporting theenvironment of a telecommunications room is the same as that of reporting the power status ofthe PDF.

If more external Boolean detection interfaces or analog detection interfaces are required toconnect humidity, temperature, or other sensors, you can configure them through the MRMU.



4-7

5 Alarm Management System

About This Chapter

Alarm management is a part of the fault management system of the OMC. The fault managementsystem provides a comprehensive set of software that enables the system to detect, isolate, andcorrect the faults of the managed device modules. When a fault, which might affect services,occurs in the MSOFTX3000, the related module generates an alarm, and the alarm managementmodule reports the alarm to the operator. The operator can take a proper measure based on thereported alarm to rectify the fault.

5.1 Subsystems of the Alarm Management SystemThe alarm system comprises the fault detection subsystem and alarm generation subsystem.

5.2 Alarm Severity and Alarm TypeThis topic describes the alarm severities and alarm types.

5.3 Alarm Box and Alarm ConsoleThis topic describes the functions and features of the alarm box and alarm console.

5.4 Alarm Report PathThis section describes the hardware alarm report path and software alarm report path.

5.5 Alarm DatabaseThis topic describes the location of the alarm database and related limitation policies.

HUAWEI MSOFTX3000 Mobile SoftSwitch CenterSystem Principle 5 Alarm Management System


5-1

5.1 Subsystems of the Alarm Management SystemThe alarm system comprises the fault detection subsystem and alarm generation subsystem.

5.1.1 Fault Detection SubsystemThe hardware detection subsystem monitors the operating status of the equipment throughhardware detection and software detection. It reports the detected faults to the operator so thatthe operator can rectify fault in time.

5.1.2 Alarm Generation SubsystemThe alarm generation subsystem collects information about faults, generates detailed alarmrecords, and notifies maintenance personnel to take a proper measure.

5.1.1 Fault Detection SubsystemThe hardware detection subsystem monitors the operating status of the equipment throughhardware detection and software detection. It reports the detected faults to the operator so thatthe operator can rectify fault in time.

l Hardware detectionThe hardware detections implemented by boards are as follows:– Board state (normal/abnormal or active/standby)

– Clock

– Temperature

– Online/Offline state

l Software detectionLogic errors can be detected through software detection. The logic errors that can bedetected are as follows:– CRC error

– Memory error

– Data consistency error

5.1.2 Alarm Generation SubsystemThe alarm generation subsystem collects information about faults, generates detailed alarmrecords, and notifies maintenance personnel to take a proper measure.

The alarm generation subsystem comprises the host alarm module, OMU alarm server module,alarm console, and alarm box. For details, see Figure 5-1. The host alarm module collects thealarms reported from other modules and the iGWB, and forwards the collected alarms to theOMU. The OMU alarm server module analyzes and stores all alarms (including those generatedby the OMU), instructs the alarm box to generate audio/visual alarms, and displays the alarmdetails and recommended solutions on the alarm console of the workstation.

5 Alarm Management SystemHUAWEI MSOFTX3000 Mobile SoftSwitch Center

System Principle


Issue 01 (2009-02-10)

Figure 5-1 Alarm generation subsystem

Other hostsoftware modules

Alarm module Alarm servermodule

Alarm console

Alarm box

LMT

Host OMU

In addition to the alarm box and the alarm console, you can obtain alarm information from thefollowing:

l Device panel on the workstation

l Status indicators on each board: For the meanings of the status indicators on various boards,see the HUAWEI MSOFTX3000 Mobile SoftSwitch Center Hardware Description or theonline Help of the LMT.

5.2 Alarm Severity and Alarm TypeThis topic describes the alarm severities and alarm types.

5.2.1 Alarm SeverityThe alarm severity indicates the severity level of an alarm.

5.2.2 Alarm TypeThis topic describes the alarm types. An alarm type indicates the nature of the alarm.

5.2.1 Alarm SeverityThe alarm severity indicates the severity level of an alarm.

In descending order of alarm severity, alarms are classified into four types:

l Critical alarm: A critical alarm indicates that a critical problem exists somewhere in thenetwork. A critical problem can be the failure, overload, or system restarting of mission-critical boards. Critical alarms should be cleared immediately. Otherwise, systembreakdown may occur.

l Major alarm: A major alarm indicates the failure of certain boards or links, such ascommunication links. Urgent action is required to rectify the fault as this type of alarmsaffects the QoS of the system.

l Minor alarm: A minor alarm indicates a non-service affecting condition that should becorrected. It can be a fault alarm or an event alarm against boards or links, for example,PCM fault alarm. This type of alarms does not affect the QoS of the system, but you needto locate and remove these faults in time.

l Warning alarm: A warning alarm indicates a potential error that may affect the QoS of thesystem, for example, board switchover and recovery. This type of alarms should be handledbased on the actual conditions.



5-3

5.2.2 Alarm TypeThis topic describes the alarm types. An alarm type indicates the nature of the alarm.

The alarm report generated by the alarm console contains the alarm type. There are three alarmtypes, namely, fault alarm, clear alarm, and event alarm.

l Fault alarm: A fault alarm indicates the failure of hardware components or exception ofsignificant functions. When a fault alarm is cleared, a clear alarm is generated. A fault alarmis paired with a clear alarm. Generally, fault alarms have a higher severity than event alarms.

l Clear alarm: A clear alarm is generated when the failure of hardware components orsignificant functions is corrected. A clear alarm is paired with a fault alarm.

l Event alarm: An event alarm indicates an event that occurs in the system. It is an occasionalevent. It reflects only the instant state of the system. There is no clear alarm for event alarms.

5.3 Alarm Box and Alarm ConsoleThis topic describes the functions and features of the alarm box and alarm console.

5.3.1 Alarm BoxThis topic describes functions and features of the alarm box.

5.3.2 Alarm ConsoleThis topic describes functions and features of the alarm console.

5.3.1 Alarm BoxThis topic describes functions and features of the alarm box.

Designed with an open structure, the alarm box provides powerful functions and featuresconvenient maintenance. The functions and features of the alarm box are as follows:

l Provide real-time monitoring and accurately generate visible and audible alarms of thefollowing severities: critical, major, minor, and warning. Alarms are both visual andaudible. The alarms provide information to help the operator to take a proper measure.

l Work in conjunction with the alarm console. This ensures optimal use of the alarm consoleand helps the operator to perform operations with ease. The alarm box provides onlyinformation about alarm severities. The alarm console provides the details of alarms. Thus,the resources of the alarm box and the alarm console can be used efficiently.

l Support flexible networking. The alarm box can be connected to the OMU or the alarmworkstation based on the actual conditions.

l Provide powerful serial port communication functions. There are eight serial ports on thealarm box, namely, four RS-232 serial ports and four RS-422 serial ports. Up to five serialports can be used for external communications at the same time. The communicationdistance of RS-232 serial ports can reach 80 meters and that of the RS-422 serial ports canreach 100 meters.

l Provide the system-down notification function. When the system breaks down, a system-down message is reported to the alarm box.

l Provide the alarm sound function. The volume of the alarm sound produced by the alarmbox can be adjusted manually. Alarm sound for major, minor, and warning alarms can be


System Principle


Issue 01 (2009-02-10)

muted. Alarm sound for critical alarms, however, cannot be muted. The purpose is to keepthe operator remained of the critical fault in the system.

l Provide the remote alarm and remote alarm sound control functions. By connecting to aremote sound box, the alarm box can transfer alarm information to a maximum of 30 metersin real time. Alarm sound can also be muted through the remote alarm sound control switch.The remote alarm sound control switch can be a maximum of 30 meters away from thealarm box. This is convenient for the operator to maintain the alarm box remotely.

l Provide simplified fault location and convenient maintenance functions. The operator canlocate faults of the alarm box quickly and accurately through the maintenance serial port.

l Support flexible power supply. The alarm box supports a variety of power supplies,including 220 V AC, 110 V AC, and -48 V DC. This can meet the requirements of differentapplication scenarios.

l Deliver proven environment specifications. The reliability, security, and electromagneticcompatibility (EMC) features have passed the environment, EMC, and EMI tests.

l Provide environment-friendly features. The alarm box is small, elegant, and easy to install.It can display alarms in graphics.

For more details, see the user manual delivered with your alarm box.

5.3.2 Alarm ConsoleThis topic describes functions and features of the alarm console.

The alarm box provides only visible and audible alarm severity information. The alarm consoleon the workstation provides the details about alarms.

The alarm console is significant for maintenance personnel. To correctly display the alarms ofthe MSOFTX3000 in real time, the alarm console provides alarm view, query, and managementfunctions as follows:

l Provide real-time view and conditional real-time view of current alarms.

l Support combined query of a particular category of alarms and dynamically update thequery results.

l Provide detailed interpretation of alarm records and display the handling methods in realtime.

l Support the printing of displayed alarms (in the alarm interpretation format) and the real-time printing of alarms.

l Provide the mute and reset functions and support operations on the indicators.

5.4 Alarm Report PathThis section describes the hardware alarm report path and software alarm report path.

5.4.1 Hardware Alarm Report PathThis section describes the hardware report path.

5.4.2 Software Alarm Report PathThis topic describes the alarm report path of the host software and OMU software.

5.4.1 Hardware Alarm Report PathThis section describes the hardware report path.



5-5

All the boards of the MSOFTX3000 are intelligent boards. These boards can monitor their ownstatus, operational conditions, and external interfaces, test and indicate the operating status, andreport hardware abnormalities to upper-level equipment. The upper-level equipment can monitorthe operating status of the lower-level equipment, report the detected abnormalities to the higher-level equipment, and perform an active/standby switchover as required. Hardware alarms areclassified into the following types:

l Alarms about the physical hardware (such as the SMM, server board, and switch board)and the environment, for example, board status (board present, board powered-off, boardnot present), fan rotation speed, temperature, voltage, and current. This type of alarms isreported by the SMM to the OMU through the maintenance plane.

l Alarms about the hard disk, RAID, and network port. This type of alarms are reported bythe IMU to the OMU through the maintenance plane.

Figure 5-2 shows the hardware alarm report path of the MSOFTX3000.

Figure 5-2 Hardware alarm report path

IMU

OMU

SMU

Alarmbox

Alarmconsole

SWU

Alarmreport

Alarmreport

Alarmdisplay

Basebus

Basebus

Basebus

Basebus

Alarmdisplay

Alarmreport

Alarmreport

5.4.2 Software Alarm Report PathThis topic describes the alarm report path of the host software and OMU software.

Software alarms are associated with events such as process fault, service process overload, andCPU overload.

Both the host software and the OMU software can generate software alarms. For the hostsoftware modules, alarms are sent to the alarm module, which then transfers the alarms to theOMU alarm server module for processing. For the OMU, the alarms are directly sent to the alarmserver module for processing.

5.5 Alarm DatabaseThis topic describes the location of the alarm database and related limitation policies.


System Principle


Issue 01 (2009-02-10)

5.5.1 Location of the Alarm DatabaseThe alarm database is located in the OMU database. It stores information such as the alarm IDand alarm type.

5.5.2 Alarm Limitation PolicyAs the number of alarms increases, the free space on the memory is getting smaller. It is necessaryto adopt certain policy to ensure that the alarm database does not exceed the storage space ofthe memory.

5.5.1 Location of the Alarm DatabaseThe alarm database is located in the OMU database. It stores information such as the alarm IDand alarm type.

For V200R008C01, the alarm database can store a maximum of 0.1 million alarm records.

5.5.2 Alarm Limitation PolicyAs the number of alarms increases, the free space on the memory is getting smaller. It is necessaryto adopt certain policy to ensure that the alarm database does not exceed the storage space ofthe memory.

The MSOFTX3000 adopts the following alarm limitation policies:

l Alarm deletion strategyHistory alarms can be retained for a maximum of 90 days only. Not more than 0.1 millionalarms can be stored on the system.

l Alarm deletion timeIf the system finds that the number of alarms exceeds 0.1 million when adding new alarmsto the alarm database, it deletes the earliest alarms automatically. At 03:00 a.m. every day,the system checks whether any alarm has been retained for more than 90 days. If such analarm is found, the system deletes the alarm automatically.



5-7

6 Time Synchronization

About This Chapter

This topic describes the functions and principles of time synchronization.

6.1 NTP FunctionThe MSOFTX3000 uses the Network Time Protocol (NTP) to realize time synchronization. Thistopic describes the working principles of the NTP.

6.2 Time Calibration Principles and ProcedureThe OMU synchronizes with the NTP server (external time source). The internal modules of theMSOFTX3000 synchronize with the OMU. This topic describes the time calibration principlesand procedure.

HUAWEI MSOFTX3000 Mobile SoftSwitch CenterSystem Principle 6 Time Synchronization


6-1

6.1 NTP FunctionThe MSOFTX3000 uses the Network Time Protocol (NTP) to realize time synchronization. Thistopic describes the working principles of the NTP.

6.1.1 Definition of NTPThe network time protocol (NTP) is used for time synchronization. This topic provides thedefinition of the NTP.

6.1.2 Working Principles of NTPThe NTP system contains two parts: the NTP client and the NTP server. This topic describesthe working principles of the NTP.

6.1.3 Networking of NTPThis topic describes the networking of the NTP.

6.1.1 Definition of NTPThe network time protocol (NTP) is used for time synchronization. This topic provides thedefinition of the NTP.

The NTP is derived from the time protocol and ICMP timestamp messages. It is used for timesynchronization between the distributed time server and the client. The purpose of the NTP isto enable the time synchronization between all devices across the network that have time andensure the time consistency between them. A device running the NTP can not only synchronizewith the time source but also serve as a time source for other devices. In this way, the time onall devices is consistent after the devices exchange the time information and synchronize witheach other. In practice, an accuracy of 1 millisecond to 50 milliseconds can be achieved throughthe NTP.

6.1.2 Working Principles of NTPThe NTP system contains two parts: the NTP client and the NTP server. This topic describesthe working principles of the NTP.

The NTP client and NTP server send the data packets carrying their respective time informationto each other. In this way, the NTP client obtains the time information. Then, the NTP clientfigures out the best time through the time selection algorithm and correct the time. Figure 6-1shows the interaction process and working principle of the time synchronization.

6 Time SynchronizationHUAWEI MSOFTX3000 Mobile SoftSwitch Center

System Principle


Issue 01 (2009-02-10)

Figure 6-1 Principle diagram of time synchronization

NTP data packet 10:00:00 a.m.

NetWork

NTP Client (OMU) NTP Server

10:00:00 a.m. 11:00:01 a.m.NTP data packet

NetWork


11:00:01 a.m. 11:00:01 a.m.10:00:00 a.m.

NetWork


NTP data packet

NetWork


NTP packet arrived at 10:00:03 a.m.

1

2

3

4

The time synchronization process is as follows:

1. The NTP client sends an NTP data packet requesting synchronization to the NTP server.The data packet carries the timestamp of leaving the NTP client. For example, the timestampis 10:00:00 a.m., as shown in Figure 6-1.

2. When the NTP data packet reaches the NTP server, the NTP server adds the timestamp ofitself, that is, 11:00:01 a.m..

3. The NTP server sends the received data packet to the NTP client. The timestamp (11:00:02a.m.) of the NTP server is added to this data packet.

4. When the NTP client receives the response data packet from the NTP server, the NTP clientadds a new timestamp, that is, 10:00:03 a.m..

At present, the NTP client obtains sufficient time information to calculate the two importantparameters required for time correction:l Time delay of a cycle required when the NTP message is sent and received

l Time offset between the NTP client and the NTP server

Therefore, the NTP client can set its own clock based on the two parameters to synchronize theclock with that of the NTP server.



6-3

Figure 6-2 shows how to calculate the time offset and delay in the NTP.

Figure 6-2 Calculating method for time offset and delay

t0

t3

t1

t2

NTP ServerNTP Client

The NTP server sends the response packet to the NTP client. The response packet includes timet0 at which the NTP client sends the request packet, time t1 at which the NTP server receivesthe request packet, and time t2 at which the NTP server sends the response packet. The NTPclient can receive time t3 at which the response packet is received from the NTP server. Themethods for calculating the delay and time offset are as follows:

l Delay = (t3 - t0) - (t2 - t1)

l Offset = [(t1 - t0) + (t2 - t3)]/2

NOTE

Offset indicates the deviation between the node in the computer data network and the NTP server.

In general, the data transmission backbone network is configured with one or more NTP servers.The nodes in the backbone data transmission network send the time synchronization request tothe NTP server. The clocks of the nodes in the entire network are synchronized through the NTPtime correction function.

6.1.3 Networking of NTPThis topic describes the networking of the NTP.

The time synchronization is better when the number of clock sources is smaller. Because of theenormous network, it is not realistic to connect all devices in the network to the same time server.Thus, in the Network Time Protocol (NTP) model, hierarchical structure that is often up to 15layers is adopted. The main reference sources that are synchronized with the national standardclock through a wired or wireless system are connected to the frequently visited resource suchas the backbone gateway. The main reference resources run in the network as primary timeservers.

The NTP nodes form the time trace system in hierarchical structure. The node on the top layer(first layer) traces the national standard time. The node on the second layer traces the nationalstandard time through the node on the first layer. Each node keeps a certain precision timeaccording to its own clock. In addition, the node automatically sends the request for correctingthe time in appropriate correction cycle.

NTP is used to send the time information of the primary time servers to other time servers throughthe network. In addition, it is used to check the clock of every server periodically to reduce theerror caused by the device or transmission fault. Some NTP hosts or gateways in the local areanetwork (LAN) run as secondary time servers. These secondary time servers send the timeinformation to other hosts in the LAN through the NTP. To improve the reliability, install less


System Principle


Issue 01 (2009-02-10)

accurate but cheaper radio clocks on the selected hosts as a backup. When the primary orsecondary time servers are faulty or when the communication between the hosts and the timeservers fails, the radio clocks can provide the time information. Figure 6-3 shows the networkingstructure.

Figure 6-3 Networking structure

Client

Tertiary time server

Secondary time server

Primary time server

National standard time server

Layer 1

Layer 2

Layer 3

Layer 4

NOTE

The servers and clients are relative concepts. The device that provides the time is the server, and the devicethat receives the time is the client.

6.2 Time Calibration Principles and ProcedureThe OMU synchronizes with the NTP server (external time source). The internal modules of theMSOFTX3000 synchronize with the OMU. This topic describes the time calibration principlesand procedure.

The OMU is the core functional entity for the time calibration of the MSOFTX3000. The NTPserver, OMU subsystem, host subsystem, and RTC subboard work together to calibrate the timefor the MSOFTX3000. The RealTime Clock (RTC) subboard, which is equipped with anoscillator, provides accurate time. When the NTP server is unavailable, the MSOFTX3000obtains the time from the RTC subboard. During the time calibration, the OMU can not only



6-5

function as a client to connect the NTP server but also function as a server to provide time forthe host. The NTP server may be a dedicated time server or embedded in the NMS.

Figure 6-4 shows the logical structure of the MSOFTX3000 time calibration system.

Figure 6-4 Logical structure of the MSOFTX3000 time calibration system

NTP Server NTP Server NTP Server……

UPB

SMM

UPB

UPB

Master OMURTC Slave OMU RTC

NTP

NTP

……

NOTE

l Up to four NTP servers can be connected to the MSOFTX3000. The NTP server and configurationparameters are configurable.

l An RTC subboard is attached to the back board of the OMU. If no NTP server is configured or theconfigured NTP servers are unavailable, the OMU obtains the time from the RTC subboard andprovides the time for the host.

The MSOFTX3000 calibrates the system time according to the following procedure:l The active OMU synchronizes with the NTP server according to the fixed time. It inserts

the time into the operating system of itself and the RTC subboard on the back board. Ifnone of the NTP servers is available, the OMU synchronizes with the RTC subboardaccording to the fixed time to set the system time. The OMU synchronizes with the NTPserver by using the NTP. Driver interfaces are adopted between the OMU and the RTC.

l The standby OMU synchronizes with the active OMU. It inserts the time into the operatingsystem of itself and the RTC subboard on the back board. When the standby OMUsynchronizes with the active OMU, the active OMU must minimize the network delay. Thestandby OMU does not synchronize with the NTP server unless the standby OMU changesto the active state.

l When providing time for the standby OMU and host, the active OMU first obtains the timefrom the RTC. If the operation fails, the active OMU obtains the system time from its ownoperating system.

l The host synchronizes with the active OMU by using the NTP according to the fixed time.If the communication between the host and the OMU fails, the boards run according totheir own time.


System Principle


Issue 01 (2009-02-10)

NOTE

Three time-related terms are described as follows:

l Universal Time Coordinated (UTC): The time of the time zone at 0 degrees geographic longitude.Equivalent to the Greenwich Mean Time (GMT). Also called the standard time. The UTC time isadopted by the NTP server.

l Local mean time: It is the time of the local time zone without counting the daylight saving time(DST). Also called the local standard time in this document.

l Local time: It is the local mean time plus the DST offset. If the DST is not enabled or the date is notin the DST period, the local time is the same as the local mean time.



6-7

7 CDR and Charging

About This Chapter

The call detail record (CDR) and charging is an important function of the telecommunicationnetwork. The MSOFTX3000 generates CDRs, pre-processes them, and sends them to the billingcenter.

7.1 Basic ConceptsThis topic describes the basic concepts related to charging.

7.2 CDR GenerationThis section describes the mechanism, process, and scenarios of CDR generation.

7.3 CDR DeliveryThis section describes the delivery process and the delivery modes for the original CDRs andfinal CDRs.

7.4 CDR StorageThis section describes the storage modes of the original CDRs and final CDRs.

7.5 CDR BackupThis topic describes the backup modes of original CDRs and the first copy of the final CDRs.

HUAWEI MSOFTX3000 Mobile SoftSwitch CenterSystem Principle 7 CDR and Charging


7-1

7.1 Basic ConceptsThis topic describes the basic concepts related to charging.

7.1.1 Charging SchemeThis topic describes the charging schemes of the MSOFTX3000.

7.1.2 CDR ClassificationA CDR is a call detail record (CDR) generated by the MSOFTX3000. It is a charging data unitstored in the memory of the WCCU/WCSU and on the hard disk of the iGWB. The format ofthe data unit is defined. There are several ways to classify CDRs. The name of a CDR variesaccording to the classification criteria.

7.1.3 CDR InterfaceThis section describes the CDR transfer protocols, formats of CDR files, and formats of CDRcontents.

7.1.4 CDR EncodingThis section describes the CDR encoding schemes.

7.1.1 Charging SchemeThis topic describes the charging schemes of the MSOFTX3000.

Host ChargingIn this scheme, the host records all information on each call conversation, and generates a detailCDR based on pre-determined charging data. A CDR refers to a data unit that is generated inthe host for a call and is used to accommodate original charging information in a particularformat.

Offline ChargingIn this scheme, call CDRs are analyzed and processed according to the service provider'srequirements. The specific fee consumed by each subscriber or trunk during a period of time iscalculated with defined charging regulations taken into consideration. This process is carriedout on a dedicated device in the offline mode, and thus not conducted in real time. Generally, abilling center is responsible for offline charging.

Online ChargingIn this scheme, the online charging system is responsible for providing, in the shortest time, callCDRs generated by the MSOFTX3000 to a settlement center through the network, so that serviceprovider can obtain the latest fee information of customers against possible or potential profitloss.

The MSOFTX3000 charging system often uses the online charging scheme to implementcharging. The iGWB preprocesses CDRs, stores CDRs to a buffer, and provides billinginterfaces.

Real-Time ChargingIn real-time charging mode, the system charges a subscriber for the ongoing service and deductspayment from the account in real time. If the account balance is insufficient, the system sends

7 CDR and ChargingHUAWEI MSOFTX3000 Mobile SoftSwitch Center

System Principle


Issue 01 (2009-02-10)

an instruction to forcibly terminate the ongoing service. In this mode, the charging response timeis measured by a time unit less than one second. A typical application scenario of real-timecharging is Prepaid Service (PPS), which is implemented in accordance with the CAMELprotocol. In PPS charging mode, the account balance reduces as the call continues. When theaccount balance is insufficient, the system releases the call.

7.1.2 CDR ClassificationA CDR is a call detail record (CDR) generated by the MSOFTX3000. It is a charging data unitstored in the memory of the WCCU/WCSU and on the hard disk of the iGWB. The format ofthe data unit is defined. There are several ways to classify CDRs. The name of a CDR variesaccording to the classification criteria.

Classification Based on the Storage Location

Based on the storage location, CDRs are classified into the following types:

l Original CDRs: Original CDRs refer to the charging data units that are generated by theMSOFTX3000 initially and stored in the memory of the WCCU/WCSU. In normalcircumstances, the MSOFTX3000 automatically transfers original CDRs over an internalEthernet to the iGWB in real time.

l Final CDRs: After receiving original CDRs from the MSOFTX3000, the iGWB first storesthese CDRs on a hard disk. Then, the iGWB sorts the CDRs, converts the CDRs into therequired format, and saves the processed CDRs to the hard disks in certain classificationmodes. These processed CDRs are called final CDRs. Final CDRs provide a key basis forsubscriber charging and cross-network settlement. In normal circumstances, the billingcenter (BC) acquires final CDRs from the iGWB automatically and periodically.

Classification Based on the Generation Process

Based on the generation process, CDRs are classified into the following types:

l Intermediate CDRs: If the duration of a call is longer than the value of the long-call CDRtimer, the system generates an intermediate CDR for every expiry of the timer.

l Last CDRs: When releasing a call after the conversation is complete, the system generatesa last CDR.

If the duration of a call is shorter than the value of the long-call CDR timer, the system onlygenerates a last CDR that records all the activities of the call. If the duration of the call is longerthan the value of the long-call CDR timer, the system generates intermediate CDRs and a lastCDR. In this case, the last CDR records only the call activities during the last interval of thetimer.

NOTE

An intermediate CDR records the call activities only during an interval of the timer. The BC charges asubscriber by accumulating the call expense in all the intermediate CDRs and the last CDR.

7.1.3 CDR InterfaceThis section describes the CDR transfer protocols, formats of CDR files, and formats of CDRcontents.



7-3

CDR Transfer Protocols

Using the standard FTP/FTAM protocol, the iGWB proactively or passively transfers the CDRsgenerated by the MSOFTX3000 to the BC over an FTP interface or an FTAM interface.

Formats of CDR Files

The MSOFTX3000 supports CDR files in the following formats:

l Binary format: Binary CDR files are used for the MSOFTX3000 to interwork with 2Gequipment. Binary CDR files are not recommended, except when the current office is areconstructed 2G office, a 2G office in China, or a special office.

l ASN.1 format: The Abstract Syntax Notation One (ASN.1) standard describes complexdata structures explicitly and thus is widely used as a syntax notation standard for theapplication layer. Both Huawei and the 3GPP organization recommend ASN.1 CDRs.

Formats of CDR Contents

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

7.1.4 CDR EncodingThis section describes the CDR encoding schemes.

Binary Encoding Scheme

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

ASN.1 Encoding Scheme

The ASN.1 encoding scheme adopts the Tag, Length, and Value (TLV) data structure. Thisscheme defines basic data structures such as the Integer, Boolean, and octet string. A combinationof any of these basic data structures results in a more complex data structure.

An ASN.1 CDR consists of one or more TLV units. A field in the CDR is identified by anidentifier and is resolved based on the length indicator and the value of this field.

7.2 CDR GenerationThis section describes the mechanism, process, and scenarios of CDR generation.

7.2.1 CDR Generation MechanismThis section describes the mechanism of CDR generation.

7.2.2 CDR Generation ProcessThis topic describes the working process of the charging system.

7.2.3 CDR Generation ScenariosThis topic describes the CDR generation scenarios.


System Principle


Issue 01 (2009-02-10)

7.2.1 CDR Generation MechanismThis section describes the mechanism of CDR generation.

Structure of the Charging SystemWhen processing a call, the WCCU of the MSOFTX3000 generates original CDRs based on thecollected call data and stores them in the CDR pool. Through a specific sliding window protocol,the MSOFTX3000 transfers the CDRs in the CDR pool to the iGWB with the help of the internalcommunication system. The iGWB then stores, processes, and transfers CDRs to the BC throughthe WAN/LAN. According to the information in final CDRs, the BC of a PLMN carrier generatesbilling invoices for purposes of subscriber charging and cross-network settlement. Figure 7-1shows the structure of the MSOFTX3000 charging system.

Figure 7-1 Structure of the MSOFTX3000 charging system

Billing center

OMU remotemaintenance terminal

MSOFTX3000iGWB

OMU local maintenanceterminal

SWP

Network managementcenter

MML

FTP/FTAM

MML

Local telecommunications room

WAN/LAN

WAN/LAN

Remote end

LAN: Local Area Network WAN: Wide Area NetworkFTP: File Transfer Protocol MML: Human-Machine LanguageFTAM: File Transfer Access and Management Protocol

Working Principles of the Charging SystemFigure 7-2 shows the logical structure of the MSOFTX3000 charging system.



7-5

Figure 7-2 Logical structure of the charging system

Call controlmodule

CDR pooliGWB BC

WCCU

The charging system of the MSOFTX3000 consists of the WCCU, iGWB, BC, andinterconnection accessories.

l Call control module of the WCCUThe call control module generates original CDRs and stores them temporarily in the CDRpool of the WCCU.

l CDR pool of the WCCUThe CDR pool is an area in the memory that stores the CDRs generated by the call controlmodule of the WCCU. The WCCU transfers the stored CDRs to the iGWB in real time.The active WCCU sends CDR data to the standby WCCU in real time, which minimizesdata loss caused by board failure.The MSOFTX3000 defines alarms and call restriction thresholds for the free space of theCDR pool. When 20% of the WCCU CDR pool is occupied, an alarm is generated, butcalls are not restricted and the CDRs are not affected. When the free space of the CDR poolis less than 1% of the CDR pool size, an alarm is generated, and calls are restricted. TheCDRs are affected. You can configure the thresholds of the free space for the CDR pool incommand line mode. When the free space is below the threshold, the system generates analarm and determines the numbers of calls to be restricted according to the free space ofthe CDR pool and the CDR increase rate.

NOTE

Before loading data onto the WCCU or upgrading the WCCU, you must run CDR-related commands onthe local maintenance terminal (LMT), for example, running a command to initiate immediate transfer oforiginal CDRs to the iGWB, to protect the WCCU/WCSU against possible CDR loss.

l iGWBThe iGWB resides between the MSOFTX3000 and the BC. It receives, preprocesses, andcaches CDRs. The iGWB also functions as a billing interface.

l BCBased on the final CDRs received from the iGWB, the BC generates billing invoices forsubscribers.The BC is not a part of the MSOFTX3000.

7.2.2 CDR Generation ProcessThis topic describes the working process of the charging system.

Figure 7-3 shows the working process of the charging system.


System Principle


Issue 01 (2009-02-10)

Figure 7-3 Working process of the charging system

CDRpool of

theWCCU

CDRpool of

theWCCU

ActiveiGWB

StandbyiGWB

BC

Communication system of the MSOFTX3000

MSOFTX3000

1. When a call is terminated, the WCCU generates and temporarily stores the charginginformation in its buffer (that is, the CDR pool).

2. The content and format of the original CDRs generated by the MSOFTX3000 do not meetthe requirements of the BC. Thus, the CDRs must be preprocessed before being sent to theBC. The iGWB resides between the MSOFTX3000 and the BC. It is responsible forreceiving, preprocessing, and temporarily storing CDRs in a buffer. It is also responsiblefor providing the billing interface function. The WCCU sends CDRs from the CDR poolto the iGWB in real time through the BASE bus. The iGWB stores the original CDRs asfiles.

NOTE

For details about the working principles of and operations on the iGWB, refer to the HUAWEIiGateway Bill User Manual.

3. The iGWB sorts the original CDRs, converts them from the binary format to the text formator ASN.1 format, and generates the final CDRs. The iGWB then saves the final CDRs todifferent channels based on the classification of CDRs. Figure 7-4 shows how the iGWBpreprocesses CDRs.



7-7

Figure 7-4 Procedure for preprocessing CDRs by the iGWB

Receives CDRs, and through a particularprotocol ensures that CDRs are receivedwithout repetition or loss.

Network module

Directly saves the CDRs received bynetwork module and generate originalCDRs.

Front saving module

Combines and sorts CDRs according to therequirement, and then transmits them to theback saving module.

CDR processing module

Saves the CDRs by channel, generate finalCDRs, and submits them to the billingcenter.

Back saving module

Service flow of access point process

FTP/FTAM

Generates andtransmits CDRs

MSOFTX3000

BC

NOTE

The system is configured with active/standby iGWBs, which back up the CDRs in real time to avoidloss of charging data due to the failure of the active iGWB.

For details about the working principles of and operations on the iGWB, refer to the HUAWEIiGateway Bill User Manual.

4. To ensure reliable transfer of final CDRs to the BC, the iGWB communicates with the CDRcollector of the BC through the standard File Transfer Protocol (FTP) or File TransferAccess & Management Protocol (FTAM).

NOTE

If the FTP protocol is in use, the iGWB supports two modes of CDR transfer. In pull mode, the CDRcollector (client) acquires CDRs from the iGWB (server) in a proactive manner. In push mode, theiGWB (client) transfers CDRs to the CDR collector (server) in a proactive manner.

If the FTAM protocol is in use, the iGWB serves as the responder and the CDR collector as theinitiator. The iGWB communicates with the CDR collector in a way similar to that with the FTPprotocol.

7.2.3 CDR Generation ScenariosThis topic describes the CDR generation scenarios.

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


System Principle


Issue 01 (2009-02-10)

Table 7-1 Generation scenarios of original CDRs

CDR Type WhetherFinal CDRIs in ASN.1Format

WhetherFinal CDRIs in BinaryFormat

CDR Generation Scenarios

MOC CDR(includingemergencycall CDRs)

Y Y If a call originated by a non-IN mobilesubscriber is answered, the MSC generatesa mobile-originated call (MOC) CDR forthe caller when the call is terminated or thelong-call CDR timer expires.

MTC CDR Y Y If a call is received by a non-IN mobilesubscriber or by an IN mobile subscriberwhose VMSC does not provide the SSPfunction, the MSC generates a mobile-terminated call (MTC) CDR for the calleewhen the call is terminated or the long-callCDR timer expires.

CFW CDR Y Y Subscriber B is a non-IN mobile subscriberand is provisioned with the call forwardingservice. Subscriber C is the forwarded-tosubscriber of B. When subscriber A callssubscriber B, subscriber B has the incomingcall addressed to subscriber C. If subscriberC answers the call, the MSC generates a callforwarding (CFW) CDR for subscriber Bwhen the call is terminated or the long-callCDR timer expires.If subscribers A, B, and C are registeredwith the same MSC/VLR, the MSCgenerates an MOC CDR for subscriber A,a CFW CDR for subscriber B, and an MTCCDR for subscriber C when the call isterminated or the long-call CDR timerexpires.

MO_SMSCDR

Y Y If a short message sent by a mobilesubscriber reaches the short message center(SMC) successfully, the MSC generates amobile-originated SMS (MO_SMS) CDRfor the sender.During short message communication,characters of a short message aretransmitted over a signaling channel.Compared with the CDR for an ordinarycall, an SMS CDR additionally records thecontent of a short message, result of theshort message service, number of bytes inthe short message, and SMC address.



7-9




MT_SMSCDR

Y Y If a mobile subscriber receives a shortmessage from the SMC successfully, theMSC generates a mobile-terminated SMS(MT_SMS) CDR for the recipient.

TRANSITCDR

Y Y When an incoming trunk originates a call,the MSC (usually a TMSC) analyzes thecall and connects it to an outgoing trunk. Inthis case, the call is neither originated norterminated in the local MSC. To calculatethe charge for the use of inter-office trunks,the MSC generates a TRANSIT CDR whenthe call is terminated or the long-call CDRtimer expires.

GWO CDR Y Y When an incoming trunk originates a call,the MSC (usually a GMSC) analyzes thecall and connects it to an outgoing trunk. Inthis case, the call is neither originated norterminated in the local MSC. If the type ofthe incoming office direction is "Localnetwork" and the type of the outgoing officedirection is "Other network" (Other PLMNor PSTN), the MSC generates an outgoinggateway exchange (GWO) CDR when thecall is terminated or the long-call CDRtimer expires.

GWI CDR Y Y When an incoming trunk originates a call,the MSC (usually a GMSC) analyzes thecall and connects it to an outgoing trunk. Inthis case, the call is neither originated norterminated in the local MSC. If the type ofthe incoming office direction is "Othernetwork" (Other PLMN or PSTN) and thetype of the outgoing office direction is"Local network", the MSC generates anincoming gateway exchange (GWI) CDRwhen the call is terminated or the long-callCDR timer expires.Only the ASN.1 encoding scheme providesa GWI CDR.


System Principle


Issue 01 (2009-02-10)




ROAM CDR Y N Only the ASN.1 encoding scheme providesa ROAM CDR.A call is addressed to a non-IN mobilesubscriber roaming outside the homePLMN. If the call must be routed to theGMSC of the home PLMN, the GMSCgenerates a ROAM CDR for the calleewhen the call is terminated or the long-callCDR timer expires.

LocationUpdate(VLR) CDR

Y N Only the ASN.1 encoding scheme providesa Location Update (VLR) CDR.When a mobile subscriber updates thelocation with the VLR, the local MSCgenerates a Location Update (VLR) CDR.

CALLATTEMPTCDR

N Y When a call is a transit call, an inter-network transit call, a call routed out of theGMSC, or a call routed to the GMSC, theMSC generates a CALL ATTEMPT CDRif the call setup fails.A CALL ATTEMPT CDR is used to recordthe network resources used by anunsuccessful call. It is the same as aTRANSIT CDR, an OT_TRANSIT CDR,a GWO CDR, or a GWI CDR, except thatthe cause value of call release in the CALLATTEMPT CDR is unsuccessfulCallAt-tempt. Based on the cause value of callrelease, the BC sorts out a CALLATTEMPT CDR from other similar CDRs.Only the binary encoding scheme providesa CALL ATTEMPT CDR.



7-11




MOI CDR N Y Assume that the MSC in office A cannotfunction as the SSP, the MSC in office Bcan function as the SSP, office A routes theIN calls in office A to office B through theOverlay mode, and the MSC in office Btriggers the IN services. When a non-INsubscriber in office A or incoming trunkcalls IN subscriber X (non-forwarding call),office A routes the call to office B.Therefore, office A cannot obtain theprecise location of IN mobile subscriber X.After triggering the IN service, office B canobtain the precise location of IN mobilesubscriber X. If subscriber X answers thecall, when the call ends or the timer of longtime call CDRs expires, the MSC in officeB generates a CDR called IN pickup CDRor MOI CDR. The CDR is provided for theBC, and is used to charge the callerprecisely.The MOI CDR is generated only after theOverlay incoming call triggers the called INservice. When the mobile IN networkadopts networking of the target network,the MSC does not generate the MOI CDR.Only the binary encoding scheme providesan MOI CDR.

LCS CDR(including theMT-LR, MO-LR, and NI-LR)

Y N If the MSC receives a location request ofany type from the BSC or the RNC, theMSC generates a CDR called locationservice CDR or LCS CDR for the locationoperation. The LCS CDRs are classifiedinto the following types: MT-LR, MO-LR,and NI-LR.The LCS CDR records the location method,location time, and location results.Only the ASN.1 encoding scheme providesan LCS CDR.


System Principle


Issue 01 (2009-02-10)




SS_ACTCDR

Y N When a mobile subscriber performs a callunrelated operation, such as registering,canceling, activating and deactivating thesupplementary service (SS), the MSCgenerates a CDR called supplementaryservice CDR or SS_ACT CDR for theoperation.Only the ASN.1 encoding scheme providesan SS_ACT CDR.

CHECK_IMEI CDR

Y N If the MSC invokes the Check IMEI flowin the process of the location update and theservice access, the MSC generates a CDRcalled check IMEI CDR or CHECK_IMEICDR.Only the ASN.1 encoding scheme providesa CHECK_IMEI CDR.

QUERY_HLR CDR

Y N During a call connection, if the callee is anon-IN mobile subscriber, the MSCrequests route information from the HLRthrough the MAP signaling, and the HLRreturns the MSRN to the MSC through theMAP signaling, the MSC generates a CDRcalled HLR Interrogation CDR.If the callee is an IN mobile subscriber, theMSC needs to query the HLR twice. Bydefault, the MSC generates an HLRInterrogation CDR when querying the HLRfor the second time. If you set Ticketcontrol flag to Generate HLR query CDRafter getting T-CSI by using MODGBILLCTRL, the MSC generates an HLRInterrogation CDR when querying the HLRfor the first time. That is, the MSC generatestwo HLR Interrogation CDRs.Only the ASN.1 encoding scheme providesan HLR Interrogation CDR.



7-13




TCAMELCDR

Y N During a call connection, if a mobilesubscriber registers the CAMEL service(with the T-CSI), receives a call, andanswers the call, the GMSC (SSP)triggering the IN service generates a CDRcalled TCAMEL callee CDR or TCAMELCDR when the call is terminated or thelong-call CDR timer expires.Only the ASN.1 encoding scheme providesa TCAMEL CDR.

CommonEquip CDR

Y N During a call connection or conversation, ifthe MSC in office A uses the public deviceresources (such as conference resources) inoffice A or in the MSC of office B, the MSCin office A generates a CDR calledCommon Equipment Usage CDR orCommonEquip CDR.Only the ASN.1 encoding scheme providesa Common Equipment Usage CDR.

7.3 CDR DeliveryThis section describes the delivery process and the delivery modes for the original CDRs andfinal CDRs.

7.3.1 CDR Delivery ProcessThis topic describes the CDR delivery process.

7.3.2 Delivery Modes of Original CDRsThis section describes the delivery modes of original CDRs.

7.3.3 Delivery Modes of Final CDRsThis section describes the delivery modes of final CDRs.

7.3.1 CDR Delivery ProcessThis topic describes the CDR delivery process.

The WCCU is responsible for charging in the MSOFTX3000. The charging information is firststored in the host CDR buffer, and then transferred to the iGWB through the CDR deliveryprocess. On the iGWB, the charging information is stored in the format of files. The charginginformation on the iGWB is sent to the billing center (BC) periodically over a data link. Figure7-5 shows the process of CDR generation and storage.


System Principle


Issue 01 (2009-02-10)

Figure 7-5 Process of CDR generation and storage

WCCU module

WCCU module

Host CDR pool

Host CDR pool

iGWB BC

UDPconnectionon the Base

planeWAN/LAN

MSOFTX3000

1. After each conversation, the WCCU generates original CDRs and stores them in the CDRbuffer of the board.

2. The MSOFTX3000 sends the CDRs in the CDR pools of the WCCU to the iGWB in realtime through the UDP connection on the Base plane. The CDRs are stored in the format ofCDR files on the iGWB to form the original CDRs.

3. If the iGWB communicates with the CDR collector in the BC through the FTP, thefollowing two modes are supported:l The iGWB serves as the server, and the CDR collector serves as the client. The CDR

collector actively collects CDR files from the iGWB.l The iGWB serves as the client, and the CDR collector serves as the server. The iGWB

actively sends CDR files to the BC.

NOTE

If the iGWB communicates with the CDR collector through FTAM, the iGWB can serve as the responder,the CDR collector as the initiator, and the communication mode will be similar to that when the FTP isadopted.

7.3.2 Delivery Modes of Original CDRsThis section describes the delivery modes of original CDRs.

The original CDRs are generated by the MSOFTX3000 and are stored in the memory of theWCCU. After the original CDRs are generated, the host combines all the CDR transmissionpaths of the WCCU through the UDP connection of the Base plane. The CDRs are stored in theformat of CDR files on the iGWB.

7.3.3 Delivery Modes of Final CDRsThis section describes the delivery modes of final CDRs.

After receiving the original CDRs, the iGWB combines and sorts the CDRs and converts theirformats to form the final CDRs that comply with the requirement of the BC. The final CDRsare categorized and stored in the hard disks of the iGWB. The iGWB sends the final CDRs tothe BC through the FTP or FTAM.



7-15

7.4 CDR StorageThis section describes the storage modes of the original CDRs and final CDRs.

The iGWB stores the original CDRs from the host, and then categorizes them and converts theirformat to form the final CDRs. Subsequently, the iGWB stores the final CDRs in a particularformat. This section describes the generation, naming principles, and storage modes of theoriginal CDRs and final CDRs.

7.4.1 Storage of Original CDRsThis topic describes the naming principles and storage structures of the original CDRs on theiGWB.

7.4.2 Storage of Final CDRsThis topic describes the naming principles and directory structures for the storage of final CDRson the iGWB.

7.4.1 Storage of Original CDRsThis topic describes the naming principles and storage structures of the original CDRs on theiGWB.

The original CDRs are first saved in D:\frontsave based on the access points, such as X3KM,and then saved by date under each access point respectively. Figure 7-6 shows the directorystructure for the storage of original CDRs.

Figure 7-6 Directory structure for the storage of original CDRs

D:\FrontSave

X3KM

Date

Date

Original CDR file

……

……

……

Original CDR file

Original CDR file

Original CDR file

The original CDRs are stored in folders named by date, that is, the original CDRs generatedwithin the same day are saved in the same folder named based on the current date. For example,all the original CDR files generated on January 1, 2009 are stored in the folder named 20090101.The length of an original CDR file can be configured as along as it does not exceed the maximumvalue.


System Principle


Issue 01 (2009-02-10)

The original CDR files are named in the format of b + a nine-digit serial number + .bil. Forexample, b000000001.bil and b000000002.bil.

7.4.2 Storage of Final CDRsThis topic describes the naming principles and directory structures for the storage of final CDRson the iGWB.

Normally, the final CDRs are saved in the E:\backsave path in duplicate. Figure 7-7 shows thedirectory structure for the storage of final CDRs.

Figure 7-7 Directory structure for the storage of final CDRs

E:\backsave

Second

Final CDR file

Final CDR file

Final CDR file

Final CDR file

……

……

X3KM

Channel n

Channel 1

……

E:\backsave

X3KM

Date

Date

Final CDR file

Final CDR file

Final CDR file

Final CDR file

Channel 1

Channel n

DateFinal CDR file

Final CDR file

DateFinal CDR file

Final CDR file

……

……

……

……

……

The first copy of the final CDRs is saved in the directory of e:\backsave\AccessPointName\ChannelName\Date by access point, then by channel, and then by date.

The second copy is saved in e:\backsave\Second\AccessPointName\ChannelName. Differentfrom the first copy, the second copy is not saved separately by date in the channels. The directoryfor saving the second copy is accessible to the BC and must be deleted in real time after theCDRs are collected by the BC. Normally, no CDRs can be accumulated in this directory.

NOTE

Final CDR files can also be stored under the channels directly. In normal cases, you are advised to storefinal CDR files under the directory by channel and date.



7-17

ChannelThe CDR files meeting particular requirements are stored in the same channel. For example,CDR files of different types can be stored in different channels, that is, the CDRs of a particulartype are stored in one channel.

Naming Principles of Final CDR FilesA final CDR file is named in the format of prefix + serial number + the symbol "." + suffix. Forexample, b00000001.dat.

l PrefixThe prefix is optional and can be any string of characters. Usually, the office name is usedas the prefix. By default, the prefix is the character b.

l Serial numberThe serial number is mandatory. By default, it is an eight-digit number starting from00000001 with an increment of 1. In addition, the serial number must be smaller than99999999.

l SuffixThe suffix can be configured. By default, it is dat.

Final CDR FilesThe generation of a final CDR file depends on two conditions: size of the file and generationduration of the file. The two conditions are equally effective. After being created, a final CDRfile is closed when the file size or generation duration reaches the upper limit. Subsequently, anew final CDR file is created.

A final CDR file contains one or more final CDRs, as shown in Figure 7-8.

Figure 7-8 Format of a final CDR file

Final CDR 1Final CDR 2Final CDR 3 …… Final CDR n

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

7.5 CDR BackupThis topic describes the backup modes of original CDRs and the first copy of the final CDRs.

CDR backup on the iGWB is a network backup function. To ensure the security of CDRs, theiGWB can back up the CDR files to the peer iGWB node or the third-party server in real time.

CDR backup on the iGWB is implemented by using the FTP. During the CDR backup process,the iGWB serves as the FTP client, and the backup destination serves as the FTP server. Figure7-9 shows the implementation principle of CDR backup.


System Principle


Issue 01 (2009-02-10)

Figure 7-9 Implementation principle of CDR backup

iGWB(FTP Client) FTP Server

CDR file

Before backing up the CDRs, ensure that the backup source and destination have enabled theFTP function and that their available disk space is sufficient. You also need to configure datafor the backup of the CDRs, for example, the IP address of the FTP server, IP address forcommunication between the iGWB and the FTP server, user account and password for loggingin to the FTP server, backup time, backup task number, backup source path, and backupdestination path.

After the related data is configured on the iGWB, the system starts searching for all the originalCDR files at the time point configured on the iGWB, and then backs up in sequence the CDRfiles to the FTP server. If the interval between two consecutive searching operations isconfigured, the system searches for a second time the original CDR files in the specified pathwithin the backup period and backs up the newly generated original CDR files to the FTP server.

7.5.1 Backup of Original CDRsThis topic describes the backup mode of original CDRs.

7.5.2 Backup of Final CDRs (the First Copy)This topic describes the backup mode of final CDRs (the first copy).

7.5.1 Backup of Original CDRsThis topic describes the backup mode of original CDRs.

For the backup of the original CDRs, one access point usually maps one backup task, that is,you need to create a CDR backup task with the backup source path set to the path of the originalCDR, and the information on the access point of the backup source path is required. For example,you can use D:\frontsave\X3KM as the backup source path.

7.5.2 Backup of Final CDRs (the First Copy)This topic describes the backup mode of final CDRs (the first copy).

The iGWB supports the backup of final CDRs (the first copy). For the backup of final CDRs,one channel usually maps one backup task, that is, you need to create a CDR backup task withthe backup source path set to the path of the final CDRs, and the information on the channel ofthe backup source path is required. For example, you can use D:\backsave\X3KM\detail as thebackup source path.



7-19

8 Final CDRs

About This Chapter

This topic describes the types and formats of final CDRs supported by the system.

8.1 Types of Final CDRsThis topic describes the types of final CDRs supported by the system.

8.2 Format of Final CDRsThis topic describes the formats of final CDRs supported by the system.

HUAWEI MSOFTX3000 Mobile SoftSwitch CenterSystem Principle 8 Final CDRs


8-1

8.1 Types of Final CDRsThis topic describes the types of final CDRs supported by the system.

The MSOFTX3000 supports the following types of final CDRs:

l Mobile originated call CDR (MOC CDR) including emergency call CDR

l Mobile terminated call CDR (MTC CDR)

l Gateway outgoing call CDR (GWO CDR)

l Transit call CDR (TRANSIT CDR)

l Supplementary service actions CDR (SS_ACT CDR)

l Mobile terminated short message service CDR (MT_SMS CDR)

l Mobile originated short message service CDR (MO_SMS CDR)

l Call attempt CDR (CALL_ATTEMPT CDR)

l Gateway incoming call CDR (GWI CDR)

l Roaming CDR (ROAM CDR)

l Common equipment usage CDR (CommonEquip CDR)

l Call forwarding CDR (CFW CDR)

l Mobile originated - instead CDR (MOI CDR)

l Terminated CAMEL visit CDR (TCAMEL CDR)

l Location service CDR (LCS CDR)

l Check IMEI CDR (Check_IMEI CDR)

l HLR interrogation CDR (QUERY_HLR CDR)

8.2 Format of Final CDRsThis topic describes the formats of final CDRs supported by the system.

The formats of final CDRs are related to the types of final CDRs in the MSOFTX3000. Fordetails, see HUAWEI iGateway Bill User Manual.

8 Final CDRsHUAWEI MSOFTX3000 Mobile SoftSwitch Center

System Principle


Issue 01 (2009-02-10)

Documents

System Principle(V200R008C01 01)