tellin ocs technical proposal for ttsl

TELLIN OCS (ONLINE CHARGING SYSTEM) TECHNICAL PROPOSAL

FOR TATA

Huawei Technologies Co., Ltd.

All Rights Reserved

TELLIN OCS (Online Charging System) Technical Proposal

TATA CWIN Project Commercial in Confidence I

TABLE OF CONTENTS

1 Overview .......................................................................................................4

1.1 Huawei OCS for TATA Overview.............................................................................. 4

1.2 Huawei OCS Brief ..................................................................................................... 4

1.2.1 An Open and Standard platform.......................................................................... 5

1.2.2 Focus of Huawei OCS....................................................................................... 6

1.2.3 System Architecture ......................................................................................... 8

1.3 System Highlights .................................................................................................. 11

1.3.1 An Open Platform for Future Evolution ......................................................... 11

1.3.2 A Customer Oriented Convergent Charging Engine..................................... 11

1.3.3 An On-line Delivery Service Platform ............................................................ 12

1.3.4 Vendor provide on-site development for operator........................................ 12

1.4 Compliant Protocols............................................................................................... 12

2 Huawei OCS Solution for TATA................................................................13

2.1 Network Architecture & Interfaces......................................................................... 13

2.1.1 Network Architecture...................................................................................... 13

2.1.2 OCS SCP, CBP site deployment .................................................................... 15

2.1.3 Interfaces ........................................................................................................ 17

2.2 Backup and Redundancy ....................................................................................... 19

2.2.2 Automatically switching and manual switching............................................ 19

2.2.3 SCP, CBP DR Switching ................................................................................. 21

2.2.4 BMP switching ................................................................................................ 22

2.2.5 UVC DR solution ............................................................................................. 24

2.2.6 SCP/ CBP mate board adopt hot standby...................................................... 24

2.2.7 SCP & CBP 1+1 Active-Active DR .................................................................. 25

2.2.8 Data Synchronization for Active-Active DR................................................... 27

2.2.9 Signaling Switchover Scheme ....................................................................... 28

2.2.10 Signaling Switchover Suggestion.................................................................. 31

2.2.11 Bandwidth Request ........................................................................................ 32

2.3 Typical service feature process flow ..................................................................... 33

2.3.1 GSM Voice Process ........................................................................................ 33

2.3.2 CDMA Voice Process...................................................................................... 34

2.3.3 Short message PTP realization ...................................................................... 36

2.3.4 Short message PTA realization...................................................................... 37


TATA CWIN Project Commercial in Confidence II

2.3.5 Ring tong download ...................................................................................... 38

2.3.6 Short message Based recharging.................................................................. 39

2.3.7 USSD based recharge .................................................................................... 40

2.3.8 AAA based data traffic charging .................................................................... 41

2.3.9 CAP3 based GPRS data traffic charging ....................................................... 42

2.3.10 Diameter based GPRS based data traffic charging....................................... 43

2.3.11 PTT SUPPORT ................................................................................................ 44

2.3.12 BREW based charging ................................................................................... 45

2.3.13 SCP responds Mediation with charging result.MMS based charging .......... 46

2.4 Postpaid & prepaid convergent ............................................................................. 47

2.5 USSD Call back....................................................................................................... 49

2.6 Realize customer from different cities in one CUG............................................... 51

2.7 Recharging ways .................................................................................................... 53

2.8 Service Description ................................................................................................ 53

2.8.1 Typical service feature list ............................................................................. 53

2.9 TELLIN® OCS Elements ........................................................................................ 54

2.9.1 USAU ............................................................................................................... 54

2.9.2 SCP.................................................................................................................. 55

2.9.3 CBP ................................................................................................................. 55

2.9.4 BMP ................................................................................................................. 55

2.9.5 UVC ................................................................................................................. 55

2.9.6 FEP .................................................................................................................. 56

2.9.7 URP ................................................................................................................. 56

2.9.8 IWEB (Intelligent Report System)................................................................... 56

2.9.9 RBI (Recorded Bill Interface).......................................................................... 57

2.9.10 I2000 (Operations and Maintenance System) ................................................ 57

2.10 Customer Oriented Convergent Charging Engine ................................................ 58

2.10.1 Powerful Convergent Rating Engine ............................................................. 58

2.10.2 Flexible Charging Capabilities ....................................................................... 59

2.10.3 Package and Promotion ................................................................................. 64

2.11 Provision................................................................................................................. 66

2.11.1 Product information synchroize ......................................................................... 68

2.11.2 Three typical operation scenarios ................................................................. 68

2.12 Operation & maintenance....................................................................................... 70

2.12.1 Fault Management............................................................................................ 70

2.12.2 Topology Management................................................................................... 71

2.12.3 Performance Management ............................................................................. 71


TATA CWIN Project Commercial in Confidence III

2.12.4 Configuration Management............................................................................ 71

2.12.5 Call Trace ........................................................................................................ 71

3 Equipment Dimensioning..........................................................................72

3.2 List of Service Requirement and Traffic Data........................................................ 73

3.3 Calculation Process ............................................................................................... 74

3.3.1 USAU ............................................................................................................... 74

3.3.2 SCP.................................................................................................................. 75

3.3.3 CBP ................................................................................................................. 76

3.3.4 BMP ................................................................................................................. 76

3.3.5 URP ................................................................................................................. 77

3.3.6 FEP .................................................................................................................. 77

3.4 Calculation Result .................................................................................................. 78

3.5 System Configuration............................................................................................. 78

3.5.1 Central Site ..................................................................................................... 79

3.5.2 Site2/3/4/5/6 are same ..................................................................................... 79

3.6 Physical Parameter of Hardware............................................................................ 80

3.7 Rack layout and footprint....................................................................................... 81

4 Glossary .....................................................................................................82


TATA CWIN Project Commercial in Confidence Page4, Total84

1 Overview

1.1 Huawei OCS for TATA Overview

In the traditional telecom networks, telecom service subscribers can be broadly divided into two

categories according to the payment mode - prepaid and postpaid customer. The prepaid services are

provided through the Intelligent Network (IN), and the postpaid services are implemented through the

BSS/OSS. But with the rapid development of the telecom industry, the service type is evolving from

plain voice service to integrated communications including information service, content service,

transaction, entertainment, and so on. With all these different types of services have different

requirements on payment, the subscribers require payment attributes be defined for different telecom

services and can be changed at any time.

This requirement to have flexible payment attribute becomes more relevant and appropriate in the

modern society, as the individuals play more and more complex roles. When the person consumes

telecom services in different roles, the payment attributes may be different. E.g., there could be one

account owned by a family in which children in the family may have prepaid amount to spend and

parents may have postpaid payment mode. So the TTSL needs to provide unified operation and

management capabilities for both the prepaid and postpaid customers. Otherwise, it is very difficult to

change the payment attributes of the customers or to implement flexible multi-service marketing mix,

which may result in a high operating cost severely affecting the operating margin.

Also, with the popularization of data services and 3G services, the service providers are offering more

and more value added services. With this the consumption of contents is soaring rapidly and the value

chain involved in the service offering is changing frequently. In this context, the TTSL requires a system

that can implement real-time, accurate and comprehensive charging on the telecom service

consumption of the subscribers to minimize the defaulting risk. At the same time it is important for the

telecom TTSL to offer real-time experience of “transparent consumption" to the subscriber and thus

enabling avoidance of fraud and over consumption. Huawei has got a right solution to address all these

converging billing requirements through end-2-end solution - TELLIN OCS.

1.2 Huawei OCS Brief

TELLIN OCS is an integrated value-added service platform intended for future networks (including

2.5G, 3G; CDMA IS-95, CDMA2000, NGN and IMS), and it has made breakthroughs in its supported

network capabilities, flexibility and openness in service development, as well as flexibility in system

composition. It is able to provide value-added services for many networks such as

GSM/GPRS/WCDMA, CDMA, PSTN, and NGN, supporting voice, multimedia and abundant data



service capabilities, the service is convergence. The capabilities of TELLIN OCS have been developed

far beyond the concept of traditional IN. The following figure gives a concept overview:

Figure 1-1 TELLIN OCS Overview scheme

With the different architecture of traditional IN, charging point becomes really an independent point,

OCS charging part (CBP) is the convergence point deal with all voice and data service, the charging

factors have been subtract and charging rule can be configurable on-line which make the site

developing be the reality, while in tradition IN, voice and data service charging usually scattered on

different points, SCP, MMS, WAPGW, etc, which make the convergence pack almost impossible.

Huawei TELLIN OCS has open system architecture. It complies with the international specifications

such as 3GPP Online Charging System (OCS), and can easily integrate with 3rd party system such as

CRM/SCP/Mediation. It also supports real-time interface with the external financing system, payment

system and recharging system, and meets the need of service expansion of telecom operators.

1.2.1 An Open and Standard platform

Huawei TELLIN OCS supports multiple standard protocols such as EJB, Web Service and SOAP, and

supports multiple flexible interface modes such as synchronous/asynchronous, real-time or timing,

batch/piece interfaces. It also designed in the similar customer oriented data structure of CRM system,

and can integrate with the Customer Care (CC) system seamlessly.



The OCS supports the real-time charging interfaces to 3rd party application servers based on Diameter

protocol. Through the Diameter protocol, it can extend the features of the parameter easily when

charging require, and affect the billing features through the rule engine.

Figure 1-2 Open and Standard platform of TELLIN OCS

TELLIN OCS enables the TTSL's business and operation network to have the unified operation &

management capabilities with highly reliable and available full-service real-time charging capabilities.

Through TELLIN OCS, TTSL can provide customer-driven and unified service operation as well as

personalized service level agreements (SLA). TTSL can also implement integrated marketing on the

services according to different customer groups to increase the APRU.

1.2.2 Focus of Huawei OCS

Flexible and Powerful Convergent Charging Capability

• Charging at multiple levels: charging for usage of bearer layer service, charging for a service,

and charging for a content

• Charging for multiple services, such as voice, data and content service

• Charging for multiple type of networks: GSM, CDMA, UMTS and IMS

• Charging of all customers: prepaid, postpaid and hybrid customers



• Providing flexible charging mode, powerful tariff strategy, multiform bill cycle, layer based

accounts, flexible bonus

• Providing event based and session based online charging, CDR-based offline charging

•

Unified Operation Management and Customer Service

• According to the account information model, customer information model, product information

model with CRM model. The unified data model available to support mapping from business

data model to charging data model, shifting between prepaid and postpaid customers,

configuring complicated layered accounts, and simplifying the definition of new products and

packages.

• Available to enable all customers to enjoy the same level of customer service, including info

query, customer service, available products, self-service, and bill.

• Through the unified service view, to enable customer service representatives (CSRs) of the

carrier to carry out customer service and to enable the carrier to understand consumption

habits of customers and loyalty comprehensively and thoroughly, thus improving customer

relation and exploring new products

•



1.2.3 System Architecture

Figure 1-3 Telling OCS System architecture

l SCP

In the TELLIN OCS solution, the call control function is separated from the charging service, and

the charging is done by an independent Convergent Billing Point (CBP). The SCP only reserves

the call access and control function.

For voice services, after receiving the IDP/ORREQ message from the MSC/SSP, the SCP

performs simple authentication, which includes call screening and call rights control analysis, e.g.

in case of roaming, it analyzes whether the subscriber has the roaming rights; in case of an

international toll call, it analyzes whether the subscriber has the right of dialing international

numbers. After simple authentication, the SCP sends a charging request to the CBP, and instructs

MSC/SSP whether to continue or to release the call according to the result returned by the CBP.

After receiving the ODISCONNECT of the MSC/SSP, the SCP sends an expense deduction

request to the CBP, and repeats this process till the termination of the conversation.

l CBP

In the TELLIN OCS solution, the CBP implements rating, charging and accounting functions and

supports both online charging and offline charging， which the traditional IN can not support.



For real-time charging, after receiving the charging & authentication request from the SCP or data

service entities, the CBP performs budget and account reservation for the conversation duration,

and indicates the conversation duration to the SCP or other. After receiving the charge deduction

request from the SCP, the CBP deducts the expense in real time.

For the offline charging, the CBP can perform rating and expense deduction for the collected

original conversation records of the subscriber, and can perform re-rating or direct expense

deduction for the CDRs which have been rated by other system. Offline charging is a very useful

function for some instance, for example, of CBP is down or need short time stop running, then the

CDR is generate by SCP, after CBP back to normal state, the CDR of SCP will be processed.

At the bill cycle date of the subscriber, the CBP will deduct the package expense of the subscriber,

and gift away the free resources in the suite.

When the CBP detect the status of the subscriber account has change, and need the provisioning

system to make some actions (such as bring the specific services from bar to provision or from

provision to bar), then the CBP can send a command (called work order) to the Customer-Care

system or other system, and the Customer-Care or other system will provision or bar the service

according to the work order. For example, a subscriber applies for the Calling Line Identification

Presentation (CLIP) service and he/she should pay the monthly fee. But when the CBP fail to

deduct the monthly fee, then the CBP will send a work order to CC to stop the CLIP service, and

the CC will send a command to the HLR to disable the CLIP service of the subscriber.

The CBP also provides the function of generating CDR and inputting it into database for future

query.

l BMP

In the TELLIN OCS solution, the BMP implements service operation management, and provide

system management, product management, customer management & customer service,

resource management.

The BMP performs analysis and abstraction for the services in the voice service, data service and

operation support fields. Based on the system architecture of the NGOSS, it sets a data model

based on the SID core concept, sets a management function model based on the service

blueprint of eTOM, and implements multi-service integration management of the BMP.

1) Convergence management of data service and voice service

The data service and the voice service adopt a uniform service definition method, product

definition method, product subscription method, product presentation method, and subscriber

management method, then abstract unified management logic, and integrate them into a

complete telecom product system.



By abstracting the common service characteristics of the data services and voice services, the

BMP develops common service management components to adapt the difference between data

service and voice service, BMP can be defined attributes dynamically.

2) Integration management of postpaid service and prepaid service.

The product manages unified management logics and tariff definition methods to integrate

postpaid service and prepaid service.

In the BMP, the postpaid product varies from the prepaid product only in payment attribute of

product. Different or identical accounts can be defined for the postpaid product and the prepaid

product.

BMP can implement conversion between the postpaid service and the prepaid service to meet the

need of different operators.

The core components of the BMP are described below:

Point Of Sales (POS): The POS combines the functions of supporting the business hall provided

in the BMP. Namely, the business hall in the BMP performs various management access

functions via the web client side, e.g., customer management and customer service functions.

Point Of Management (POM): The POM combines the system management access functions of

the BMP.

Convergent Billing Configuration Point (CBCP): The CBCP acts as the charging configuration of

the CBP separately, as highlights of flexible configuration of the charging capability. This function

is available only to the specially trained charging configuration engineer of the operator and

Huawei on-site support engineer.

System management: System management includes the BMP, CBP and SCP management.

Customer Care: Includes customer management and customer service. Customer management

includes personal customer information management and blacklist management; the customer

services include: Customer authentication, creating/canceling accounts (by batches or by piece),

subscribing/canceling commodities, maintaining customer-user-account information, recharging

and paying, managing customer password, comprehensive query (querying all information of the

customer at a time, including basic information and extended information of the customer,

subscriber information under the customer, customer payment account information, and providing

“one-stop" consulting service for the customer).

Product Catalog: Provides service management (includes data/voice service and

postpaid/prepaid service management), service relationship management (includes dependency

and repulsion relation), product management (includes lifecycle management), product relation



management (includes dependency and repulsion relation), tariff plan management, commodity

management (includes brand management, catalog management, lifecycle management), and

commodity relation management (includes repulsion, additional and replace relation).

Resource management: Includes management of SIM card, mobile phone and number. The

functions include resource lifecycle management, resource data management (e.g., inputting

resources to database, binding number to SIM card).

Charging management: Managing the tariff of the CBP. Both the charging data, (such as pricing

plans, tariff templates, rating rules, and tariffs) and the charging process data (such as the rules of

interface adapter, authorization, rating, and accounting) can be customized. The changed data will

be uploaded into a memory database of the CBP, which does rating and charging real time.

1.3 System Highlights

1.3.1 An Open Platform for Future Evolution

• Easy to integrate with 3rd party CRM

• Easy to integrate with core network

• Easy to integrate with other VAS enablers

• A smooth way to convergent billing solution

•

1.3.2 A Customer Oriented Convergent Charging Engine

Figure 1-4 Customer-Subscriber-Account Structure Design

• Clear layer of customer, subscriber & account



• Services are easily shared by different users

• Flexible promotion & market segmentation

• Support flexible payment mode, easy to provide corporation& hybrid solutions

•

1.3.3 An On-line Delivery Service Platform

Faster Response to Market Requirements

• Less sections in E2E flow, all steps are on-line executed, shorten time to market and lower

E2E cost

• Configuration based development brings possibility and flexibility that

•

1.3.4 Vendor provide on-site development for operator

• Operators do customization via configuration GUI

1.4 Compliant Protocols

No Name Notes

1 ITUT Q.121X CS-1 recommendations

ITUT Q.122X CS-2 recommendations the protocols in ITU-T Series

2

GSM 02.78 version 6.1.0 Release 1997




the protocols in ETSI CAMEL series

3

TS 22.078 R99 & R4

TS 23.078 R99 & R4

TS 29.078 R99 & R4

the protocols in 3GPP CAMEL series

4

CDMA IS826

CDMA IS848

CDMAIS771

3GPP2 WIN Protocols

3GPP2 WIN Protocols

3GPP2 WIN Protocols

5 MTP: ITU-T recommendations Q.701-Q.710 and Q.781-Q.782 the protocols of SS7



SCCP: ITU-T recommendations Q.711-Q.716 and Q.786

TCAP: ITU-T recommendations Q.771-Q.775, Q.787

6 RFC3588 Diameter Base Protocol

7 RFC4006 Diameter Credit-Control Application

8 3GPP 32815-600 Online Charging System (OCS) architecture study

9 3GPP 32299-610 Diameter charging applications

10 3GPP 32296-610 Online Charging System (OCS): Applications and interfaces

2 Huawei OCS Solution for TATA

2.1 Network Architecture & Interfaces

2.1.1 Network Architecture

The Huawei recommend OCS network architecture is as follow:



Figure 2-1 G-C-OCS network architecture

According to the RFP requests, there are 3 years of construction, each year 20 million subscribers. The

hardware would be deployed at two geographical locations in mated pair architecture.

Take first year as example, the equipments BMP, SCP and CBP will be distributed at Delhi and

Mumbai. Each site processes the traffic of 10 million active subscribers. In case of one site fails,

another site will take over the whole 20 million traffics, as follow Fig.

Figure 2-2 Active – Active Request

The network architecture include 3 levels:

Voice & data access level which is mainly composed by MSC/SSP, AAA, GGSN, PDSN, VAS entities;

Online charging system level which is mainly composed by SCP, CBP;

Network management level which is composed of BMP, SMAP, NMS, CRM/CC, etc.

The GSM MSC/SSP and CDMA MSC/SSP are accessed to OCS by USAU, the module in USAU can

be configured into GSM or CDMA, and so the USAU can support both G & C signals.

The data entities such as SMS, MMS, WAPGW, is accessed to OCS through FEP, because different

data protocols of different data entities should be consolidated to a stand protocol by FEP, or else, all

data entities can connect to CBE directly by standard diameter protocols.

UVC is setup for all the subscribers, and OCS also will connect to the current UVC.



OCS connects to NMS through I2000 network management system. Current CRM/CC connects to

BMP through web service interface for service provision and customer care. The character of current

billing system will act as credit control for postpaid and reckoning management system.

Year 2, Year 3, is almost the same as Year 1.

2.1.2 OCS SCP, CBP site deployment

Take phase I as example, the site deployment is as follow:

Figure 2-3 PHASE 1 network architecture

In above Figure, each site have one BMP which is composed of 27 pairs ATAE blade, one SCP which

is composed of 18 pairs ATAE blade and one CBP which is composed of 43 pairs ATAE blade. SCP,

CBP pair ATAE blade adopts Hot-standby which means the processing call will not be lost during

main-standby switching. For geography disaster tolerance, Huawei adopts 1+1 Active-Active mode,

which means the capacity of each site is 20 million with 10 million active and 10 million standby, in case

one site fails, the other will take over the whole 20 million traffic.



ATAE - the advanced telecommunications application environment is Huawei provided carrier-class

processing platform of high performance. It is designed for realizing the service application of

profession and high integration.

The ATAE provides a complete service platform solution, including:

Dense processing boards

Storage schemes

Management server

Network devices

The ATAE has the following features:

High reliability

Good maintainability

Network processing capability of high performance

The ATAE meets the carrier's requirements for:

Large capacity

High performance

High reliability

High expandability

The ATAE Server adopts the architecture based on:

Processors of high performance and low power waste

Carrier grade Linux (CGL) technology

The detail information about ATAE please refers to appendix ATAE system description.

I2000 is used to monitor the warning information from all entities and assist to determine and to

initialize the DR process.

As for DR, will be described in next chapters.



2.1.3 Interfaces

The interfaces of the total system include voice access relative, data service access relative, inner

OCS relative, provision relative, other. The interfaces can be classified into voice, data, inner OCS,

provisioning and other system to cover all the RFP service requests. The interfaces included as follows

table:

AREA Interfaces

Objects

comments

SCP-CDMA

MSC/SSP

Based on IS771, IS826, and

IS848.

SCP-GSM

MSC/SSP

Base on CAMEL II

SCP-PSTN SSP Base on INAP

SCP-TELLIN

URP

Base on IS826

SCP-Current VC Current Vendor’s protocol

VOICE

SCP-Huawei

UVC

Huawei protocol based on

INAP Execute

CBP-Logica

SMSC

SMPP+/PSA V3.4

GGSN-SCP CAP3 GPRS

GGSN-CBP DIAMETER GPRS

CBP-AAA RADIUS+

CBP-MMSC

CBP-WAP GW

CBP-Brew

ADS/Chat

CBP-OSM

DATA

CBP-PTT Server

XML / SOAP



USAU-SCP For system notifications

through USSD; for subscriber

information query etc.

SCP-CBP

FEP-CBP

DIAMETER

SCP-UVC Execute

Inner OCS

BMP/SCP/RBI TCP/IP

Billing – CBP FTP Provisioning

Customer Care -

CBP

Web service

Other Bank/Payment

GW

ISO8583(Huawei protocol)

For data service, If data entities can not support diameter interface:

One solution is to interconnect with FEP directly, if the data entities support real time charging, it can

connect to FEP directly; mediation only process in non real time mode, by collect CDR and generate

message send to FEP for charging.

Another solution is all the interface will by pass the mediation, mediation affords real time charging and

non real time charging mode, FEP only interface with mediation.

The interfaces between FEP and different data entities include mediation need more discussion.

If data entities can support diameter:

Above interface can be connect to CBP with diameter directly.

Content charging request:



For content charging, also has two solution, one is the content should be managed and rated by

current system, such as mediation, and then the rated fee will be send to OCS for deducting the money.

Another solution is the content should be managed by the current system, such as mediation, and then

the content ID to OCS, OCS will rate the content and deduct the money.

2.2 Backup and Redundancy

The request of DR is as follow Fig shown:

Figure 2-4 Active – Active Request

The architecture of network is as Figure 2-3. I2000 is to monitor all the entities for and give the warning

information, the DR initialize can be automatic from I2000, or the engineer can log on to the DR node to

initialize by manual. The DR node includes CRM, BMP, SCP, CBP, Data entities.

Normally, when disaster happens, it may include redundancy node switch and all link (SS7, TCP/IP)

switching. Switching may have two ways, automatic and by manual. Because SCP and CBP adopt

Diameter messages to communicate, is should be in the same place, so we do not recommend SCP

and CBP switch respectively, because SCP should not send diameter message to CBP which is locate

thousands away for real time charging, the link may not stable.

2.2.2 Automatically switching and manual switching

Automatically switching means redundancy node and link (SS7, TCP/IP) will be switched automatically.

Product such as USAU, SCP, CBP fails down may cause STP switch the link automatically, then DR



node such as SCP will monitor the redundancy NO7 link has been activated and initiate the DR

process automatically. As follow fig shown:

Figure 2-5 Normal DR Process

Also, I2000 can analyze the warning information and determine the disaster has happened, and then it

will send command automatically to DR node to initiate the DR process.

Manual switching means redundancy node and link (SS7, TCP/IP) be switched by manual. I2000 will

warning the disaster has happens. Then engineer will send command to DR node to initialize the DR

process and switch the link between product and redundancy by manual. Usually link switch is

operated after DR Pre-initiate finished. As follow fig shown:



Figure 2-6 DR Process by manual

Also, the engineer can log on the redundancy node to initiate the redundancy process by manual; this

can be done in case of I2000 failure.

2.2.3 SCP, CBP DR Switching

As follows, SCP, CBP DR switching can be realized automatically:



Figure 2-7 SCP, CBP DR Switching

l Dual Switch: in case of active node (SCP, CBP) is down, the dual switch happened automatically.

l Disaster Detect: in case of dual switch failure, USAU will block the link with STP. STP detects the

disaster happens and blocks the signal point of product node and initiates the redundancy signal

point to redundancy node. BMP of product deduct the float IP of product SCP, CBP failure, then

switch the TCP/IP link to redundancy SCP, CBP automatically.

l DR Pre-Initiate: the redundancy SCP will capture the active of redundancy signal point and

initiate DR Pre-initiate automatically, and SCP will send a diameter message to CBP, then CBP

will execute the DR Pre-initiate automatically.

l Take Over: After the DR Pre-initiate finished, the redundancy node will take over the traffic.

Also, the switching can by manual.

2.2.4 BMP switching

As follows, BMP switching can be realized automatically or by manual:



Figure 2-8 BMP DR Switching

l Dual Switch: in case of active node (BMP) is down, the dual switch will happened automatically.

l Disaster Detect: in case of dual switch failure, I2000 detect the disaster happens and can send

command automatically or by manual to redundancy BMP.

l DR Pre-Initiate: The redundancy BMP accepts the command and initiates DR Pre-initiate

process.

l Link switch: The product SCP and CBP will check the float IP of product BMP failure, and switch

the TCP/IP link to redundancy BMP automatically. As for CRM link switch have two solutions, one

is switch the link by manual. And another is by configure two inner IP address in router in active

and standby mode, the active inner IP address connect to product BMP, the standby inner IP

address connect to redundancy BMP, in case of the product BMP fails, the router will switch the

link to standby IP, so the connection of CRM to redundancy automatically. Because the router

may be sensitive may cause some “error switching”, so we suggest CRM switch by manual.

l Traffic take Over: After the DR Pre-initiate finished, the redundancy BMP will take over the traffic.



2.2.5 UVC DR solution

Figure 2-9 UVC DR

The UVC disaster tolerance adopts 1+1 Active-Standby mode. The switch is similar to BMP.

2.2.6 SCP/ CBP mate board adopt hot standby

SCP and CBP are all in 1+1 mated-pair architecture for each node, in this way, one ATAE board is the

active, the other is the standby. When the active fails, the standby will take over the load automatically.

Main mate board Service guard is used to monitor the running state of the dual mate, and ensures the

time consistency between active and standby board. TELLIN’s own developed hot standby technology

ensures that the call instance in active node and standby node are synchronized and all the calls in

progressing will not be lost when switch over.

Following is a detail illustration of SCP hot standby architecture:



Figure 2-10 Local SDU 1+1 Backup Switch Scenario

During normal situation, the active node and the standby node are both running the application. All

incoming messages from external entities, including SS7 messages, database manipulation, FEP

messages are replicated from active node to standby node, which ensures that the Active & Standby

node get the same input. According to the computer conception model, if there is an identical input,

there is always an identical output. Hence, the state and call instance data will be kept in consistency in

both active and standby node.

Active and standby nodes both generate Response, but only the active node’s Response will be send

out.

Figure 2-11 SCP and CBP dual-network connection

SCP and CBP adopt dual-network connection, and SCP mate switch or CBP mate switch does not

effect the call processing. Local mate board switchover does not affect the interfaces to external

entities. Voice, data, SMP management, report and CDR query will go smoothly just as before.

2.2.7 SCP & CBP 1+1 Active-Active DR

Geographical redundancy improves the reliability of both SCP and CBP besides local backup. Both

SCP and CBP have their associative backup in another city. The data in SCP and CBP is



synchronized in one direction, from the active to the redundancy node, to guarantee the security of

data.

Huawei adopt 1+1 Active-Active mode, which means to set up two redundancy node for two product

nodes. As follow fig shown:

Figure 2-12 ATAE Active-Active Solution

l This solution has 2 levels of data synchronization.

i) Memory DB level;

ii) Physical DB level 2.

l As per the memory DB level synchronization, the active ATAE board will contain both the product

data and the redundancy data. Huawei’s Mem synchronization will be applied for 2 different sites.



l Physical DB level synchronization uses the VVR data sync method for data sync between two sites.

The product and the redundant data will be present in the same disk array but in different volume.

l For the mirroring of data base with in a site Informix CDR will be used for data sync between the

active and backup database.

l In this approach, Active board will be configured for 50 % performance and the rest 50 % will be

kept reserved for the disaster recovery case.

l Disaster Recovery Mechanism, In case of Disaster, the redundancy volume will be activated so that

the Active board is enabled for 100% performance.(20million)

2.2.8 Data Synchronization for Active-Active DR

The data synchronization in BMP, SCP, and CBP include two parts, memory database synchronization

realized by specially designed technology as the red line shown, and psychical database

synchronization which we will adopt VERITAS synchronization technology.

For memory data synchronization, is as follows:

Figure 2-13 ATAE memory synchorize



The product CBP memory data is synchronized to redundancy node real time, the execution can be

invoked by pair active or standby board. The redundancy board accepts the synchronized data, it can

be refreshed into memory board.

For physical data synchronization, the mechanism of VARITAS data synchronization is as follow fig.

Figure 2-14 VVR data synchronization process

Please refer to 《Introduction to VERITAS GDR solution》 appendix document Huawei submitted for detail.

2.2.9 Signaling Switchover Scheme

Signaling networking for geographical redundant system is as below:

Storage Replicator Log



Figure 2-15 Figure 5 – Networking for Signaling

When redundant equipment takes over the service, all signals which used to the active equipment will

be forwarded to the redundant equipment. This is so-called signaling switchover. Two signaling

switchover solutions are introduced in the following parts.

Signal Redundancy Scheme

1、Signaling switchover scheme

In the standby signaling point scheme, the SCCP signaling management function is used to complete

the switchover. It is necessary to set the standby signaling point of the active equipment as the

signaling point of the standby equipment.

The SCCP will automatically transfer the signaling service to the standby signaling point when it

detects that the signaling point state of the active equipment is "Inaccessible". That is, all messages will

be sent to the DPC of the standby equipment, thus realizing the signaling switchover.

2、Cooperation needed:

Below lists the necessary jobs for signal redundancy solution:

1）Links connect redundant equipments to STP.

2）New signal codes are needed for redundant equipments. Therefore these redundant equipments

could share the same GT with the active equipments

3）Signaling data is to be configured in STP and adjust the backup data regarding to the sub system.

For example, before redundant configuration:

Index Signal Node Name

Destination Signal Code

Local Signal Code

Backup Signal Index

11 Active 06FF01 1B0801 NULL 12 redundant 06FF02 1B0801 NULL

STP A STP B

Active Redundancy



Configure 06FF02 as the backup of 06FF01:

Index Signal Node Name

Destination Signal Code

Local Signal Code

Backup Signal Index

11 Active 06FF01 1B0801 12 12 redundant 06FF02 1B0801 NULL

When the active equipment fails, STP will switch the signals to the redundant equipments automatically.

If manual switchover is preferred, all links to redundant equipment should be blocked. Then unblock

these links in case of catastrophe.

3、Features of this solution:

1）Both automatic and manual switchovers are support

2）The active/redundant equipments connect to the same STP

3）The active/redundant equipments support GT and DPC addressing mode.

GT Translation Scheme

1 Switchover principle

GT Translation Scheme: Signaling switchover via modification of GT translation data in STP. When GT

addressing is available in the whole signaling network, this switchover scheme is adopted.

Figure 2-16 GT Translate

1）DPC+GT translation method

STP A has the data of state-inside signal point SPa, but has not the data of state-outside signal point

SPb. The GT translation type of SPb should be set as DPC+GT in STP A, and in this case, DPC is the

signal point code of STP B. Therefore signals from STP A to SP B will be forwarded to STP B.

2）DPC translation method

The GT translation type of SPb in STP B is set as DPC, therefore all signals from STP B to SPb will

reach SPb via the direct route between STP B and SPb.



2 Cooperation Needed

1）Link connects redundant equipment to HSTP A.

2）New signal codes are needed for redundant equipments. Therefore these redundant equipments could share the same GT with the active equipments

3）n case of switchover, replace the GT of active equipment with the GT of redundant equipment in HSTP A mannually.

Figure 2-17 Redundant signaling Scheme

Usually 8613900126, the GT in HSTP A, will be translated as the DPC of the active equipment:

06FF01. All signals from HSTP A to 8613900126 will be forwarded to the active equipments.

In case of switchover, translation target of 8613900126 in HSTP A should be changed to the DPC of

redundant equipment: 06FF02. All signals from HSTP A to 8613900126 will be forwarded to the

redundant equipment.

3 Features of this scheme:

1）Only manual switchover for fault-tolerance is supported.

2）The active/redundant equipments could connect to different STPs.

3）GT addressing mode is the unique address mode for both the active and the redundant equipments.

2.2.10 Signaling Switchover Suggestion

For single signal point networking, STP will automatically switch over in case of the failure of the active

equipment.

ST STP B

Active Redundant

GT: 8613900126 SPC: 06FF01

GT: 8613900126 SPC: 06FF02



For the multiple signal points networking, in case of a single signal point failure, automatic switchover

will possibly result in a inconsistency where some signals are forwarded to the redundant equipment

and some signals are forwarded to the active equipments.

Auto-switchover happens only after links of one signal point are all blocked. However, some troubles,

such as database problem, along with the active links, will not cause the auto-switchover.

Therefore, manual-switchover is recommended against the auto-switchover. After maintenance staff

finds the trouble and goes through the procedure of trouble-analysis and determination, the calls could

be switched over manually to the redundant system.

2.2.11 Bandwidth Request

The bandwidth include memory synchronization, physical synchronization calculation two level:

SCP: only physical by VVR, each CAPS need 0.1k byte data need to be synchronized.

CBP: both memory and physical,

For physical only 5% CAPS need to synchronize the data, each CAPS 4k.

For memory each CAPS need to synchronize 650 byte data.

BMP: only physical by VVR, each CAPS need to synchronize 4k data.

UVC: only physical by VVR. Each CAPS need to synchronize 4k data

SCP bandwidth = 0.1K * SCP CAPS/Usage Ratio * 8/1024/1024

CBP memory bandwidth = 650 byte * CBP CAPS * 8 / Usage Ratio

CBP physical bandwidth = 4k * 5% * SCP CAPS *8 /1024/1024

BMP physical bandwidth = 4k * BMP CAPS * 8/1024/1024

UVC physical bandwidth = 4k * UVC CAPS *8/1024/1024

Adopt fiber cable, the Usage Ratio can be 70%

So the total data = SCP + CBP + BMP + UVC = 304 M bits/s.

If adopt duplex link, may need 150 M bits bandwidth.

Please refer to BOQ part for detail.



2.3 Typical service feature process flow

2.3.1 GSM Voice Process

1) The IN subscriber invoke a call, MSC/SSP will trigger the service to SCP by IDP.

2) SCP will regulate the calling and called number, and send diameter CCR to CBP.

3) CBP authenticate the calling party, to check the account state, if pass reserve the fee and return

CCA to SCP with call continue.

4) SCP send RRBE, AC, CONNECT to MSC/SSP.

5) MSC/SSP sends ANALYZD to SCP.

6) MSC/SSP report ACR to SCP, SCP makes the simple process and sends CCR to CBP for

charging.

7) CBP will reserve the fee for the call according to the product and price plan that the subscriber

authorized. CBP send he CCA back to SCP



8) The call finished MSC/SSP send ERB to SCP, SCP send CCR(Terminate) to CBP

9) CBP pricing, accounting and finish the conversation, then send CCA(Terminate) TO SCP.

10) SCP send RC to MSC/SSP to release the call.

2.3.2 CDMA Voice Process

1) The IN subscriber invoke a call, MSC/SSP will trigger the service to SCP by ORREQ.


3) CBP authenticate the calling party, to check the account state, if pass return CCA to SCP with call

continue.

4) SCP returns orreq to MSC/SSP.

5) MSC/SSP sends ANALYZD to SCP.

6) SCP makes the simple process and sends CCR to CBP for charging.





8) SCP sends anlyzd message back to MSC/SSP.

9) MSC/SSP interconnects with HLR to obtain the TLDN and setup the call. After the call setup,

MSC/SSP sends OANSWER to SCP.

10) SCP transfer regulates the parameters into CCR and send to CBP to charging.

11) CBP begin to charging the account.

12) Once the reserved time is used up (usually 6 minutes), the SCP will send the CCDIR to MSC/SSP

to check if the call is still exist.

13) MSC/SSP sends ccdir back to SCP.

14) SCP will invoke CCR again to CBP to apply approved talk time.

15) CBP responses talk time in CCA..

16) The talk time applies & response circles periodically.

17) The calling party hangs up the call, the MSC/SSP.



2.3.3 Short message PTP realization

1) The subscriber sends a short message to called party, SMSC send AUTH REQ to SCP.

2) SCP regulate the number into diameter parameter and send CCR to CBP.

3) CBP price the SMS according to the product the subscriber authorized, and deduct directly from

the account. CBP send CCA to SCP with the charging flag.

4) SCP send AUTH RSP back to SMSC.

5) SMSC send the short message to called party.

6) If send failure, SMSC shall send REFUND REQ to SCP, SCP send to CBP, CBP refund the

deducted fee.



2.3.4 Short message PTA realization

1) Subscriber sends a short message to SMSC for download content (Ring tone for example).

2) SMSC transfer to message to SPMANAGER (can be SMS gateway) for price the contended,

SPMANAGER will interconnect with SP to obtain the content ID.

3) SPMANAGER price the content.

4) SPMANAGER send FEE REQ to SCP for deducting the content.

5) SCP generate diameter CCR to CBP, CBP deduct fee from the account and send result CCA back

to SCP.

6) SCP return FEE RSP to SPMANAGER.

7) If the subscriber downloads the content failure, SPMANAGER will generate REFUND REQ to

SCP.

8) SCP generate refund CCR to CBP, CBP refund the money back to the account.



2.3.5 Ring tong download

1) The user compiles a short message like RT + 12345 and send to 6666 (SP number)

2) SMC send this short message to content GW, and content GW send the message to 6666-SP

3) 6666-SP analyze the short message and authenticate the RT 12345, then find the charging class

number of such ring tong (12345)

4) 6666-SP sends the charging class number to FEP-CBP for pricing and deducting the number.



2.3.6 Short message Based recharging

Have two modes, mode one:

1) Subscriber send recharge credit card recharging access code to SMSC, SMSC transfer the

message to payment gateway.

2) Payment gateway interconnects with BANK to apply the money from the credit card.

3) Payment GW send recharge request to SCP, SCP generate CCR request to CBP.

4) CBP recharge the account and response result to SCP.

5) SCP will generate a short message send to SMSC to inform the subscriber recharge info.

Mode two:

1) Subscriber send recharge card recharging access code + voucher number to SMSC, SMSC

transfer the message to SCP.



2) SCP analyzes the short message and interacts with VC according to AC + voucher number, obtain

the value of the voucher card.

3) SCP generate recharge CCR request to CBP.

4) CBP recharge the account and response result to SCP.

5) SCP will generate a short message send to SMSC to inform the subscriber recharge info.

2.3.7 USSD based recharge

1) PPS subscriber A composes a string *888*37986567561124# for example and sends by its own

cell phone as a user initialed USSD request to the network.

2) MSC/SSP will forward a PUSSR message to HLR, because the access code 888 is not configured

to be handled locally.

3) After receiving PUSSR message, HLRa will trigger service and send PUSSR message to SCP,

because triggering condition of subscriber A’s U-CSI or UG-CSI has been matched. (If some HLR

can not support U-CSI or UG-CSI, it can forward PUSSR message to SCP according to

predefined forwarding rules of that special access code)

4) After receiving PUSSR message, SCP generate CCR to CBP.

5) CBP performs recharge process and sends CCR message to SCP.

6) SCP send PUSSR RSP to HLR.

7) After receiving the PUSSR res message, HLRa sends it to MSC/SSP.



8) Subscriber A will get a message displaying on its cell phone screen.

2.3.8 AAA based data traffic charging

1) Data traffic based charging is the conversation based charging. AAA send RADIUS+ REQ to SCP.

2) SCP regulating the number, and send diameter CCR to CBP to apply the data traffic or time.

3) CBP preserve the money form the account, and deduct the money of last preserved. CBP send

the CCA back to SCP.

4) SCP respond AAA with the result



2.3.9 CAP3 based GPRS data traffic charging

1) The IN subscriber invoke a GPRS request; SGSN will trigger the service to SCP by IDP GPRS.


3) CBP authenticate the calling party, to check the account state, if pass reserve the fee and return

CCA to SCP with call continue.

4) SCP sends RRBE GPRS, AC GPRS, CONTINUE GPRS to SGSN.

5) SGSN send GREATE PDP REQ, SGSN response, MS will act the PDP, begin to surf.

6) SGSN report ACR GPRS to SCP, SCP makes the simple process and sends CCR to CBP for

charging.





8) The surf finished, SGSN deactivate the PDP connect, after deducting the money, SCP send

RELEASE GPRS to SGSN

9) SGSN send del PDP REQ to GGSN, and GGSN response.

2.3.10 Diameter based GPRS based data traffic charging

1) The IN subscriber invoke a GPRS request; SGSN send CREATE PDP REQ to GGSN.

2) GGSN send CCR to OCS for authentication. OCS return the result.

3) The subscriber begin to surfing, GGSN send CCR to OCS in cycle mode to charging the

subscriber.

4) The subscriber quit the network, GGSN send CCR to report the situation of used quota and

charging the account.



2.3.11 PTT SUPPORT

1) Mediation system collects all the CDRs from the PTT server and generates SOAP/XML REQ to

SCP for pricing and charging. All pricing related parameters are included in the REQ.

2) SCP regulates the number and includes the parameters, send CCR to CBP.

3) CBP pricing and deducting the fee from the balance, send CCA back to SCP.

4) SCP responds Mediation with charging result.



2.3.12 BREW based charging

It can be two modes according to the capability of BREW ADS.

Charging through Mediation:

1) Mediation system collects all the CDRs from the BREW ADS server and generates SOAP/XML

REQ to SCP for deducting money. Deducted fee is included in the REQ.


3) CBP deducts the fee from the balance, send CCA back to SCP.


BREW ADS interconnect with SCP directly:

1) Before downloads content, BREW ADS send HTTP/XML message to SCP.





4) SCP responds BREW ADS with charging result.

2.3.13 SCP responds Mediation with charging result.MMS based charging

It can be two modes according to the capability of MMS server.

Charging through Mediation:

1) Mediation system collects all the CDRs from the MMS server and generates SOAP/XML REQ to

SCP for pricing and charging. All pricing related parameters are included in the REQ.




MMS server interconnect with SCP directly:

1) Before send the MMS, MMS server send SOAP/XML message to SCP.




3) CBP price the item and deducts the fee from the balance, send CCA back to SCP.

4) SCP responds MMS server with charging result.

2.4 Postpaid & prepaid convergent

In Huawei OCS system, all Products Available to All Subscribers, Prepaid and postpaid can provision

same service features.

Figure 2-18 Prepaid & post use the same service

In this project, postpaid usually be charged real time through credit control.



Figure 2-19 Post paid limit control

Which means, every month, the billing system will calculate the credit limit for postpaid subscribers,

and synchronize the limit to OCS system, OCS will monitor and charge the subscriber real time, in

case of the limit is used up, the service is stopped.

For voice call, short message and multimedia message, OCS can charge from prepaid or postpaid

accounts of the hybrid subscriber, according to the different called party or time when that service

occurs. For GPRS data service, OCS can charge from prepaid or postpaid accounts of the hybrid

subscriber, according to the different time.

In case of appointed account exhausts or reach credit limit, OCS can switch to another account until all

valid accounts has been used up. For example, operator assigned prepaid account for off-peak time

voice call, but that account has been used up all balance, system can automatically switch to the

postpaid account.



2.5 USSD Call back

For postpaid, system will grant the ability for both calling and called to the subscriber who is going

abroad, he/she can make and receive calls in the foreign country, the carrier collects his/her bills from

the foreign carrier and charge for him/her.

When subscriber originates a call abroad, VMSC in VPLMN can not trigger OCS service to the home

SCP, unless it supports CAMEL protocol and the visiting carrier agrees to trigger service via CAMEL

(For this situation, please refer to the second solution for international roaming). This bring a risk for

overdraft when the subscriber roaming abroad. To solve this problem, carrier can grant only ability for

called to the subscriber who is going abroad, when he/she want to originate a call abroad, he/she can

send a USSD request to the home network, then a special equipment originate a call to the roaming

subscriber and the called party, after both of them answer the call, system merges the two calls

together. This is called USSD call back.

& Notes:

When subscriber is abroad, the MT flow can be triggered in VMSC of the domestic calling party or

GMSC of the international calling party. In order to distinguish the normal MT flow and the MT flow

originate by SSP, an UCB prefix will be added to the calling party number.

The following figure illustrates the flow of call setup procedure when the subscriber is roaming abroad.

Figure 2-20 UCB international roaming flow



(1) When subscriber A roams to a foreign country and wants to make call to subscriber B, he/she can

compose a USSD message and send.

(2) The USSD request will be sent to his/her HLR in the HPLMN via international GMSC. The HLR will

forward the USSD request to the SCP.

(3) SCP originates a call to subscriber A by send ICA and related messages to the SSP.

(4) SSP setup the call to subscriber A by send IAI and related messages to VMSC (A) via international

GMSC.

(5) Subscriber answers the call.

(6) SSP reports the event of answer to SCP via ERB message.

(7) SCP originates another call to subscriber B by send ICA and related messages to the SSP.

(8) SSP setup the call to subscriber B by send IAI and related messages to VMSC (B).

(9) After subscriber B answers the call, SCP and SSP will merge the two calls into one so that

subscriber A and B can talk to each other.

For example, a subscriber from China roams to Thailand, he/she want make a call to 01026754684 in

Beijing:

(1) he/she dials *123*01026754684#.

(2) After a few seconds, he/she will receive a call from 99901026754684.

(3) Once he/she answers this incoming call, the system will originate a call to the called party

01026754684, after the callee answers, system merges the two calls.

& Notes:

Assume UCB Service Code is ‘123’ and Prefix of UCB is ‘999’.

The subscriber does not need to mention the country code when he/she dials a domestic number.

If the subscriber wants to make a call to a number of Thailand 026745678, he/she can dial

*123*0066026745678#.

& Notes:

The subscriber must mention the country code 0066 in this situation.

& Notes:



The carrier must equip a special Huawei SSP for this solution, Huawei SCP will communicate with

Huawei SSP using an internal protocol.

Impacts to supplementary services

Supplementary service - CLIR, COLP, COLR will be disabled during the call back procedure. Please

refer to ‘Line Identification’ for more details

Minimum Balance Threshold for UCB Call

Carrier can set a threshold to the balance of subscriber, only when the subscriber has enough balance,

he/she can originate a UCB call.

Suppress Duplicate UCB Requests

After the roaming subscriber send out USSD request, the system needs several seconds to set up the

call to the subscriber. During this period, the subscriber may send duplicate requests which can make

the system set up other calls to the subscriber and it will waste the resource of the system. The TELLIN

OCS service can suppress duplicate UCB requests: from the system receives the first UCB request to

the call connected or released, succeed UCB request from that subscriber will be rejected.

If a subscriber sends another UCB request before the previous one has been connected, system will

send a notification message and discard the request.

2.6 Realize customer from different cities in one CUG



Figure 2-21 CUG of different cities

The common CUG should have same two CUG tables, and when subscriber want to join into the CUG,

the CRM should send messages to different BMP1 & BMP2 .



2.7 Recharging ways

Figure 2-22 Recharging ways

The subscriber can have multiple ways to recharge its account, can by cash, by voucher card by credit

card, etc. The interface between different recharging entities shall be more discussed.

2.8 Service Description

2.8.1 Typical service feature list

Huawei OCS system can support abundant of service features, the next table list some typical features:

SN Service Features SN Service Features

1 Voice call real time charging, including calling flow, called flow, forwarding flow. 19 Multiple accounts

2 SMS real time charging including MO and MT 20 Packages across voice, SMS, MMS &

CDMA1X/GPRS

3 MMS real time charging 21 Online charging and offline hot billings

4 CDMA1x/GPRS data service real time charging 22 First activation bonus



5 Fax/video phone charging 23 Bonus based on usage accumulation

6 Monthly rent, daily rent and weekly rent for package, for bonus 24

Bonus base on top-up card attribute, recharge date and time, accumulated top-up amount, top-up frequency etc

7 IVR/SMS self management 25 Preferential tariff based on Scratch Card

8 Online/offline notification 26 Discount based on balance usage accumulation

9 Incoming call screening 27 Discount based on when, what, who, where

10 Multilingual user interaction 28 Advanced periodic settlement

11 Support of CDMA/GSM supplementary services 29 Bonus on loyalty

12 IP international calls 30 Resource bonus, monetary bonus with independent validity period, rebated by stages

13 Unified voucher center 31 Emergency numbers, charging-free numbers, blacklist numbers

14 Familiarity & friend number 32 Credit Limit of prepaid and postpaid subscribers

15 Home Zone 33 Inactive penalty or bonus

16 Family solution 34 Call right control, service available control

17 Corporation solution 35 Stepped rating daily, per call

18 CUG 36 Brew/PTT charging

Other service feature, please refer to < Function List of TELLIN OCS for TTSL.doc >.

2.9 TELLIN® OCS Elements

2.9.1 USAU

The USAU (Universal Signaling Access Unit) is a unified narrowband/broadband signaling

access platform based on the NGN platform with large capacity and high performance which

supports both the broadband SIGTRAN and narrow-band CCS7 protocols. Its full configuration is

with three cabinets for supporting of 1,664 links (64KBps Type), or 104 links (2MBps Type).



The USAU support E1/T1, STM-1 ATM, STM-1 POS, and 100/1000M Ethernet interfaces through

the PMC pinch board, the USAU is based on high reliability design:

• Hardware and software are designed with redundancy

• Providing automatic fault detection and self-healing

• All boards are hot backup

• Enhanced protections such as power-down protection, power switch mis-operation protection,

lightning protection for the power supply system, over-/under-voltage protection, short-circuit

protection, over-current/voltage protection for the power supply and interface parts, as well as

temperature adjustment and protection functions for the power supply system

•

2.9.2 SCP

As above

2.9.3 CBP

As above

2.9.4 BMP

As above.

2.9.5 UVC

The TELLIN® Voucher Management System consists of UVC (Voucher Center) and CMP (Card

Management Point). The UVC is mainly used to store voucher cards related data, and handle the

recharge request from subscriber.

The UVC is based on high reliability design:

• It works in dual active-standby cluster system

• It adopts large-scale RDBMS (e.g., Informix) and Huawei-developed memory database

technology to provide high efficiency of accessing the database.

• Its hardware and software are designed with redundancy

• Providing automatic fault detection and self-healing



The CMP is mainly in charge of the centralized management over the creation, loading-to-

database, deletion and query of the recharge card data file.

In addition, CMP can manage recharge service data, which includes the management of

corresponding relationship between prefix of the recharge card and UVC, recharge card region,

etc. The configuration of CMP hardware is PC desktop.

2.9.6 FEP

FEP (Front End Processor) is also an interface entity between the IN system and 3rd party

systems such as banks, SMSC (Short Message Service Center), MDSP (Mobile Data Service

Platform), etc. to accomplish the conversion between different protocols so as to extend the

functions of the IN system.

2.9.7 URP

The U-SYS Universal Resource Platform (URP8100 for short) is used for narrowband media

resources. It is an intelligent peripheral of media resources in next generation network.

The URP uses industry-leading software and hardware architecture, featuring large capacity,

high integration, rich media resources, and strong service support. It also enjoys powerful

networking ability by supporting PSTN/PLMN and NGN.

2.9.8 IWEB (Intelligent Report System)

The report system can be divided into three parts, the report client, the report server, and

database proxy server. These three parts coordinately access the service database opened by

the service system.

Features of Report System

• Report Management: The report management is similar to the file management, and it aims at

managing the report template file, report file and relevant data file.

• Data Source Management: The administrator needs to write the architecture information of the

service database to be dealt into the data source, and he will design the report template file

based on these data source definitions. Meanwhile, the data source administrator needs to

configure the data source information on the basis of the database proxy server installation of

the system, and allocate the database proxy servers employed by each data source in the

access.



• User Management: The administrator can create or modify users or user groups for the report

system, and maintain the user relationship of the system, which is described in detail in the

following.

Advantages of Intelligent Report System

• Separating the report development from the service and platform development to increase the

speed of report development.

• Adopting the independent system, so the report development has no relation to service and

platform.

• Having the powerful authority management and system security is high.

• Supporting the template and customization.

• Being convenient to access for user and operator.

•

2.9.9 RBI (Recorded Bill Interface)

Huawei RBI is responsible for sending the bills generated by the SCP to the billing center. The

RBI system uses dual network adapter cards. One connects to the SCP via LAN, and the other

connects to the billing center to prohibit the billing center from directly logging in to the SCP.

The RBI collects bills from SCP using FTP and sends the bills to the billing center using FTAM or

FTP. There are several RBI in the network for Operator, depending on the amount of SCP. The

RBI hardware configuration is PC desktop or minicomputer.

2.9.10 I2000 (Operations and Maintenance System)

Being content with the Operations and Maintenance requirement, Huawei proposes an Intelligent

Network (IN) NMS (Network Management System) solution iManager I2000 special for Operator,

which involves I2000 servers and I2000 clients both for central part and remote part covering the

whole IN. I2000 will manage the Intelligent Network (IN) in an integrated way.

I2000 provides the management at the NE (Network Element) level as well as partially the

network level. The main functions include: configuration management, performance management,

topology management, fault management, security management and system management.

Some public NM tools are also available, such as data mending, database backup, statistics task

management, integrated management modules, etc.



There is no special requirement for the connection mode between I2000 and the superior NMS,

and either E1 or DCN (including DDN, ISDN, PSPDN and X.25) can be adopted. I2000 provides

alarm information, performance information, and configuration information to superior NMS via

SNMP interface.

I2000 can implement the centralized operation and maintenance over the network elements such

as SCP, SMP, USAU, etc.

I2000 offers the SNMP interface for the superior NMS, meeting the telecom carriers’

requirements on building the integrated NMS.

2.10 Customer Oriented Convergent Charging Engine

2.10.1 Powerful Convergent Rating Engine

Rating-Charging-Billing model

• Rating: According to the subscription relationship of the subscriber, obtain the rating factors

subscribed for the subscriber based on the selected tariff rule. If more than one tariff rule

applies, select the rule of the highest priority level; if they are of the same priority level, select

the most preferential one, or select the one subscribed last.

• Charging: Perform different charging schemes according to the application scenes

(authentication, rating). For example, perform budget when performing authentication; and

perform fee calculation when performing rating.

• Billing: According to the fee items, one charging event may generate multiple fee items. For

example: A subscriber roams to another city and make an international call, the fee items may

include airtime fee, roaming fee and international toll fee.



Figure 2-23 Rating-Charging-Billing Model

2.10.2 Flexible Charging Capabilities

• Flexible Tariff Strategies

Figure 2-24 Charging strategies supported by TELLIN OCS



• Multiple Charging Factors

TELLIN OCS supports many types of charging factors involved in charging when it

can acquire, and supports dynamic extension of charging factors. The charging

factors include the following types:

Charging event attribute

Charging event attributes can be calling party number, called party number, calling place, called place,

time, location, APN, duration, traffic, content type, and count based on content or transaction.

Service bearer attribute

Service bearer attributes can be quality of Service (QoS), bandwidth, and access type.

Subscriber attributes

Subscriber attributes can be subscriber type, birthday, home place, subscriber status, validity period,

brand, occupation, and company.

Account attributes

Account attributes can be account type, bill cycle, account balance status, and credit limit.

Accumulated amount

The relevant accumulated amounts also can be charging factors. For example, the accumulated

amount of toll call fee of the subscriber is used as charging factor: when the accumulated toll call fee of

the subscriber reaches $80, the rate will be off by 20% for subsequent toll call fees.

• All-around Fee Management Capabilities

TELLIN OCS provides these fee management capabilities: fee budget, fee reservation, fee

calculation. When a subscriber raises a service request, firstly the system will do the fee

budget according to the balance. Secondly, the system will reserve the specific amount of fee

to ensure the subscriber can pay for it. Finally, when the system is aware of service completion,

it will calculate the fee the subscriber should pay, and do the fee deduction.

• Powerful Fee Calculation

When calculating the fees, TELLIN OCS supports the following methods of calculating

services:

Calculate multiple different fees for one charging event.



Support multiple types of measurement and multiple units of measurement. The types of measurement

can be measuring by duration, volume (traffic) and number of times. The units of measurement can be

second, minute, hour, KB, MB, number of times, number of pages. When calculating the same fee for

the same event, different segments can adopt different measurement types and different units of

measurement. For example, the first segment is charged by duration, and the second segment is

charged by traffic.

Calculation methods can be linear calculation, reference calculation, fixed value, best calculation, and

accumulated calculation. Reference calculation means calculating one type of fee by reference to

another fee. Best calculation means multiple tariffs are configured for one type of fee, and the best

value will apply. Accumulated calculation means one fee is a result of accumulation of other fees.

The calculation precision can be round-s (e.g., the number of 2.4 is converted to 2 as an integer, the

number of 2.5 is converted to 3 as an integer), round-down (e.g., the number of 2.9 is converted to 2 as

an integer) and round-up (e.g., 2.1 is converted to 3 as an integer).

Support real-time applying the accumulated amount.

• Independently Service Control

TELLIN OCS enables subscribers to independently enjoy different services. For example, a

subscriber joins a group. The subscriber can enjoy the group’s service as a group member or

enjoy his/here personalized service as an individual. To control communication expense, an

enterprise may set an expense limit for each member. If the accumulated expense of the

enterprise’s service for a member exceeds the limit, TELLIN OCS will not allow this member to

use this group service again, but allows him to use personal services.

• Multi-Accounts Function

The logic architecture of TELLIN OCS implements the relationship between customer,

subscriber, product and account.

One subscriber may have multiple accounts

A subscriber’s different consumption fees may pay by different accounts. TELLIN OCS can support 4

types of dedicated accounts including “Promotion Monetary Account, Preferential Tariff Account,

Dedicated Monetary Account and Free Resource Account”, and the number of each type account is

configurable.



Figure 2-25 One Subscriber Uses Multiple Accounts

Different services can use different accounts

Different services of one subscriber use different accounts to pay for his/her different services. E.g. one

subscriber may an own voice-call-account, a GPRS-service-account and a SMS-account.

Figure 2-26 Different Services Use Different Accounts

Shared account



Multiple subscribers use the same account. Some or all of the fee items of each subscriber can use a

shared account. Alternatively, multiple customers, multiple products and multiple services share the

same account for payment.

The shared account provides many functions, e.g., if the operator needs to monitor the total fee of

multiple accounts, the operator can set all fees of multiple subscribers to share one account; if the

operator needs to monitor the total fee of a type of service, the operator can set fees of a service type

to use this shared account.

Different payment modes use different accounts

In order to facilitate the subscriber to pay, different accounts can be set for different payment modes.

E.g. Payment mode of an account can be configured as prepaid or postpaid.

• Real-time Credit Control

When a postpaid subscriber uses high-value services, he/she may be changed to

be a prepaid subscriber for those services, and then a certain credit balance is

granted to him. To some high-end prepaid subscribers, the carrier may grant

him/her a certain credit balance. The credit balance granted may get from the

outside system, such as CRM or an individual credit evaluation system. The real-

time credit control of TELLIN OCS is a process of rating, charging and billing

according to the granted credit, and then exercising real-time control according to

the credit balance. The real-time credit control is characterized by:

The credit balance may be money, duration or traffic.

When deducting the fee, the account balance is used first. After the account balance is used up, the

credit balance will be utilized.

After the credit balance is used up, the system will handle according to the boundary processing rule.

The boundary processing rule needs to be predefined, e.g., notifying the balance deficiency message

to the user.

• Real-time Balance Management

When a subscriber enjoys a telecom service, TELLIN OCS will reserve resources in

real time. But when the subscriber uses up the balance, rewards and free resources,

TELLIN OCS may not allow the subscriber to continue to enjoy the service. TELLIN

OCS has the following balance management functions:

1) Reservation

When receiving a call start request, TELLIN OCS reserves certain balance and

freezes it. The reservation function has the following features:



If the balance of an account is insufficient, reserve other accounts’ resources according to account

priority.

An account balance can be reserved for multiple subscribers.

Balances of different accounts can be reserved for different services used by a subscriber.

2) Return

TELLIN OCS enables returning reserved resource to account. Reasons for

replenishment may be:

Normal service rollback

Service session timeout

Un-used up reserved resources

3) Fee deduction

After a subscriber succeeds to use a service, the reserved amount is deducted from

the account. The fee deduction function has the following features:

If the balance of an account is insufficient, service fees are deducted from other accounts according to

priority.

Fees of different services used by a subscriber are deducted from different accounts. For example, toll

call fees are deducted from the corporation account and local call fees from personal account.

Fees of multiple subscribers may be deducted from an account. For example, fees of group members

are deducted from a group account.

Fees of a subscriber can be deducted from multiple accounts according to certain strategy. For

example, a subscriber has cash account and free resource account. In this case, fees can be deducted

from the free resource account first, and then from the cash account after the use amount is used up.

• Recharging

TELLIN OCS supports many recharging methods, such as: Recharge with voucher

card via IVR/SMS/USSD, recharge by cash in the business hall, recharge by bank,

ATM, USSD and SMS.

And recharging contents can be money, duration, traffic and pieces.

2.10.3 Package and Promotion

• Package Function



To attract more customers and enhance customers’ loyalty, Huawei TELLIN OCS

can provide abundance packages (bundle). To let the package to be more flexible,

TELLIN OCS package is defined with package parameters and package rule.

Through different parameters, it can generate different package tariff strategies. The

package rules of TELLIN OCS can set dynamically through the rule engine. All

service parameters can be introduced into the rules.

Figure 2-27 Service combinations to subscriber class

• Deposit Promotion Function

TELLIN OCS can provide multiple deposit promotion ways to the subscriber. For

example, when the subscriber subscribe a service after paying a $30 as a deposit,

then the deposit can be rewarded proportionally in three months or six months as

the carrier defined. The deposit promotion rule can be configured dynamically

through the rule engine. Subscriber attributes and customer attributes can be

introduced to the rules dynamically.

• Accumulation Promotion Function

The subscriber consumption accumulation methods may include: accumulated

airtime fee, accumulated toll fee, accumulated roaming fee, accumulated

international call fee, accumulated duration of local call, accumulated duration of toll



call, accumulated duration of roaming call, accumulated duration of international call,

and accumulated GPRS Flux.

• First Call Activation Promotion

After first call activation, the subscriber can get an extra bonus. The bonus could be

an extra premium, additional validity period, free talk time or free short messages.

After the subscriber bought a TELLIN OCS SIM card and use it to make the first call,

system can automatically activate the corresponding account, at the same time,

he/she will get extra bonus for the activation.

• Bonus in the Promotion Period

The carrier can launch a promotion, in a specified period, any subscriber uses a

certain type of voucher card to recharge during this period can get an extra bonus.

The bonus could be an extra premium, additional validity period, free talk time or

free short messages.

Here is some example for the promotion of recharge:

Bonus for Large Amount Recharge

In order to encourage the subscribers use large face value voucher card to recharge, the operator can

set Subscriber’s Recharge Amount to a large amount in the promotion definition.

Bonus for Special Recharge Mode

In order to encourage the subscribers use a certain recharge mode such as USSD, the operator can

set Recharge Type to USSD Recharge in the promotion definition. Thereby, the subscribers will be

glad to recharge by USSD, it can save lots of voice resources during the IVR recharge.

Bonus for Special Period

The operator can set Start Time and End Time to Christmas Day in the promotion definition. When the

subscriber recharges his account with an ordinary voucher during this period, he/she can get extra

bonus.

2.11 Provision

Huawei OCS supply Web service interfaces to interconnect with current CRM system.



Figure 2-28 OCS provision scheme

l Centralized Provisioning: open Web-service interface to external system

l Discrete Number Management: transparent to external system

l Distributed Deployment: cluster networking support multi-services

The main interfaces include:

1) Query recharges record

2) Query the subscriber’s status

3) Query the status change logs

4) Comprehensive query

5) Activate a subscriber

6) Query the price plan definitions

7) Synchronization the relation between a product and a price plan

8) Account balance query

9) Recharge with cash in the business hall

10) One-off fee deduction

11) Subscribe the Product

Etc.



2.11.1 Product information synchroize

When CBCP have configured new price plan, the CBCP will synchronize to BMP in different cities.

2.11.2 Three typical operation scenarios

1) The customer goes to CRM to authorize the service.

Figure 2-29 Service authorization

l Customers go to CRM to authorize the service

l CRM generate user information and work orders to HLR, VAS, OCS

l CRM send generated work orders to HLR, VAS and OCS respectively



2) The customer goes to CRM to order the products which will be valid next month

Figure 2-30 Order product valid next month

3) Prepaid switch to postpaid

Figure 2-31 Prepaid switch to postpaid



2.12 Operation & maintenance

Figure 2-32 OCS provides Adapter, Server, Client triple layer architecture

• I2000 Server communicates with UOA, AMOS to realize network entity monitor and

management.

• iTrace, iConfig and I2000 client provides GUI to carry out call tracing, configuration and

other management operations.

• Through UOAgent provides supporting to application related management, including topologic,

performance, logs, tracing, fault and warning.

• Through AMOS provides supporting to system (outsourcing system) related management,

including CPU, memory, storage, third party database, network traffic and etc.

2.12.1 Fault Management

• Real-time monitor of the network alarms;

• Customizing the color and sound of alarms;



• Redefining alarm levels;

• Processing alarms

• Displacing alarms

2.12.2 Topology Management

• Topology view;

• Topology object;

• NE status;

• Key index display;

• Topology location;

• Topology filter;

• Topology print

2.12.3 Performance Management

• Collecting the performance data;

• Monitoring the performance in real time;

• Generating performance alarms

• Performance report

2.12.4 Configuration Management

• Configuring the NE

• Synchronizing the configuration data

• Identifying the statuses of the configuration data with different colors

2.12.5 Call Trace

• powerful tools for call tracing, helpful for maintenance and troubleshooting

• Signaling (CAP, MAP, INAP, WIN) and TCP/IP messages (RCOMM) can be traced

• Filters definition



3 Equipment Dimensioning

ATAE parameters

• Frame Dimension：Width 19 inch, Height 14U

• Each ATAE Frame has 2 pieces of switch boards which provide 10/100/1000M ports and FC interface port and support maximum 12 pieces of processing boards

• Low power consumption: each frame less than 2830 W

• Support two kind of power: DC and AC

• High Integration: Required Rack is less 30%~50% than min-compter. One extended rack has two frame.

• High Stability: up time 99.999%

• Conform to the criterion of RoHS.

Figure 3-1 N610-22 Appearance

l Complied with: IEC60297 (19 inch)

l Rack Dimension：



› Width: 600mm

› Depth: 1,000mm

› Height: 2,200mm

› Floor Space required per rack: 0.6m2

l Internal Space：

› Depth: 850mm

› Height: total 46U (1U=44.45mm)

3.2 List of Service Requirement and Traffic Data

Huawei collected the Service Requirement and Traffic Data from the RFP/RFQ/RFI. The data are shown in the following table:

Y1 Y2 Y3

Number of Active subscribers

20M 40M 60M

Number of Idle subscribers

10M 20M 30M

Huawei proposes that the solution is distributed into 6 different sites averagely according to number segment.

Item Item Type

Default

Traffic

Data

per

Sub.

Traffic

Cal.

Mode

SCP 01

Active

Sub. Qty.

SCP 01

Idle

Sub. Qty.

SCP 01

CAPS

SCP 02

Active

Sub. Qty.

SCP 02

Idle

Sub. Qty.

SCP 02

CAPS

OCS-B S

3.000 BHCA

20,000,000

10,000,000

16,667

20,000,000

10,000,000

16,667 OCS-SMSC Charging-

SMPP+ I

0.250 BHSM

-

-

-

- OCS-SMSC Charging-

CAP3 I

- BHSM

-

-

-

-

OCS-RTBP Charging I

- BHSM

-

-

-

- OCS-MMS Charging-

Diameter I

0.060 BHMM

-

-

-

-

OCS-MMS Charging-EMPP I

- BHMM

-

-

-

- OCS-MMS Charging-CDR I BHMM



- - - - - OCS-GPRS Data

charging(CAP3) I

0.300 BHCR

-

-

-

- OCS-GPRS Data

charging (CDR) I

- BHCR

-

-

-

-

OCS-IVR Recharge I

0.030 BHCA

20,000,000

167

20,000,000

167

OCS-IVR Query I

0.060 BHCA

20,000,000

334

20,000,000

334

OCS-SMS Recharge I

0.030 BHSM

-

-

-

-

OCS-SMS Query I

0.060 BHSM

-

-

-

-

OCS-USSD Recharge I

0.003 BHCA

20,000,000

17

20,000,000

17

OCS-USSD Query I

0.006 BHCA

20,000,000

34

20,000,000

34

OCS-FNS F

3.000 BHCA

2,000,000

1,667

2,000,000

1,667

OCS-HZ F

3.000 BHCA

2,000,000

1,667

2,000,000

1,667

OCS-VPN F

0.020 BHCA

2,000,000

12

2,000,000

12

OCS-Community F

3.000 BHCA

2,000,000

1,667

2,000,000

1,667

OCS-Hybrid F

3.000 BHCA

2,000,000

1,667

2,000,000

1,667 OCS-UCB(USSD Call

Back) I

0.100 BHCA

2,000,000

56

2,000,000

56

3.3 Calculation Process

• For PPS service, the CAPS is calculated as:

eHoldingTimErlsSubscriberofNumberCAPS *

=

Assumed Main Holding Time is 70 second.

• For SMS&MMS service, the CAPS is calculated as:

• 3600

M)s*BHSM(BHMSubscriberOfNumberCAPS =

3.3.1 USAU Besides the data listed in the RFP, Huawei also provides the necessary assumption of service

traffic data to calculate the configuration. The data are shown here:

SN Service Name Item Data Unit 1 Public TCAP Links Load 0.4



2 Public Length of TCAP Message 130 Byte 3 PPS No. of TCAP Messages per Call 10 4 Home Zone No. of TCAP Messages per Call 2

Service Traffic Data assumed by vendor

TCAP Links Calculation of USAU

• For PPS service, the TCAP links is calculated as below:

Load Links TCAP *64000*28*Message TCAP of Length *Call per Messages TCAP of No. * CAPS64K) (CCS7 Links TCAP =

3.3.2 SCP

SN Service Name Item Data Unit No. of Transactions per Second on SCP 15

Avg. Length of CDR 512 Bytes per CDR

Avg. Length of Sub. Data 5000 Bytes per Sub.

CDR Storage Duration on SCP 3 Day

1 PPS

Busy Hour Per Day 10 Hour

2 SMS No. of Transactions per Second on SCP 11

3 MMS No. of Transactions per Second on SCP 11

4 IVR Query No. of Transactions per Second on SCP 15

5 SMS Recharge No. of Transactions per Second on SCP 11

6 SMS Query No. of Transactions per Second on SCP 11

7 Home Zone No. of Transactions per Second on SCP 5


TPSR=∑CAPS* No. of Transactions per Second on SCP*(1+ Redundancy Factor)

Disk Array HD=∑(CDR File Disk+ Sub. Data Disk+ Log File Disk)*Mirror Factor*(1+ Redundancy Factor)

Note: Redundancy Factor is 30%, Mirror Factor is 2.

CDR File Disk= ∑Avg. Length of CDR* ∑Number of CAPS* 3600* Busy Hour Per Day* CDR Storage Duration on SCP.

Sub. Data Disk= ∑Avg. Length of Sub. Data*Number of Subscribers.



Log File Disk=2G.

3.3.3 CBP

SN Service Name Item Data Unit No. of Transactions per Second on CBP 20

Avg. Length of CDR 512 Bytes per CDR

CDR Storage Duration on CBP 3 Day

1 PPS

Busy Hour Per Day 10 Hour

2 SMS No. of Transactions per Second on CBP 10

3 MMS No. of Transactions per Second on CBP 25

4 IVR Query No. of Transactions per Second on CBP 15

5 SMS Recharge No. of Transactions per Second on CBP 20

6 SMS Query No. of Transactions per Second on CBP 15

7 Family No. of Transactions per Second on CBP 6

8 Home Zone No. of Transactions per Second on CBP 6

9 Community No. of Transactions per Second on CBP 6


TPSR=∑CAPS* No. of Transactions per Second on CBP*(1+ Redundancy Factor)

Disk Array HD=∑( CDR File Disk + Memory Database Disk + CBP Log)*Mirror Factor*(1+ Redundancy Factor)


CDR File Disk=∑Avg. Length of CDR* ∑Number of CAPS* 3600* Busy Hour Per Day* CDR Storage Duration on CBP* successful call ratio.

Memory Database Disk (G) = Number of Subscriber/1000000*15*2.5

CBP Log (G) = Number of Subscriber/1000000*15*0.5.

Note: successful call ratio is 0.6.

3.3.4 BMP

Disk Array HD=∑(CBP physical database capacity+ Log update capacity+ Subscriber data capacity+ Operation Log capacity+ Index capacity+ Data backup capacity)*Mirror Factor*(1+ Redundancy Factor)




CBP physical database capacity= (Number of Active Subscriber + Number of Idle Subscriber)/1000000*15*2.5

Log update capacity= (Number of Active Subscriber + Number of Idle Subscriber)Number of Subscriber/1000000*15*0.5

Subscriber data capacity=( Number of Total Subscriber+ Number of Active Subscriber*5%*12)* Subscriber information Size/1024/1024

Operation Log capacity= Integrated service per day*3* log data*working day per month/1024/1024

Index capacity=( Subscriber data capacity+ Operation Log capacity)*0.5

Data backup capacity= Subscriber data capacity+ Operation Log capacity+ Index capacity

Note: Subscriber information data is 20K, log data is 0.2K.

3.3.5 URP

SN Service Name Item Data Unit No. of ISUP Messages per Call 5 Length of ISUP Message 30 Byte ISUP Links Load 0.2 MHT(S) 120 Second PA&PC Time 44 Second Erl/Sub 0.002

1 PPS

E1 load 0.8 Erl

ISUP Links (CCS7 64K) =CAPS (IVR)* No. of ISUP Messages per Call* Length of ISUP Message*8/2/64000/ ISUP Links Load

CAPS (IVR) =Erl/Sub*Number of Subscribers/MHT(s)

VP Channels= CAPS (IVR)* PA&PC Time/E1 Load

E1= CAPS (IVR)* PA&PC Time/E1 Load/30

3.3.6 FEP

SN Service Name Item Data Unit

1 SMS No. of Transactions per Second on FEP 11

2 MMS No. of Transactions per Second on FEP 11


TPSR=∑CAPS* No. of Transactions per Second on FEP*(1+ Minicomputer Redundancy Factor)

Note: Minicomputer Redundancy Factor is 30%.



3.4 Calculation Result

Central Site Site 2 Site 3 Site 4 Site 5 Site 6 Y1 Y2 Y3 Y1 Y2 Y3

USAU WCSU Board Qty. - OCS 248 248 248 248 248 248 248 248 USAU WCSU Board Qty. - UVC 2 4 6 2 2 2 2 2 USAU TCAP&MAP 64K Link Qty. - OCS 3538 3538 3538 3538 3538 3538 3538 3538

USAU-N

USAU TCAP&MAP 64K Link Qty. - UVC 26 52 78 26 26 26 26 26 CAPS 17275 17275 17275 17275 17275 17275 17275 17275 TPSR 321086 321086 321086 321086 321086 321086 321086 321086 SCP

Disk HD Qty 173 173 173 173 173 173 173 173 TPSR 530161 530161 530161 530161 530161 530161 530161 530161 Memory(G) 21 21 21 21 21 21 21 21 CBP

Disk HD Qty 209 209 209 209 209 209 209 209 CAPS 1389 1389 1389 1389 1389 1389 1389 1389 FEP TPSR 18335 18335 18335 18335 18335 18335 18335 18335 TPSR 27766 55528 83279 - - - - - RBI Disk HD Qty 6 12 18 - - - - -

URP TCAP Link Qty. (64K) 84 84 84 84 84 84 84 84 VP CH. Qty. 14667 14667 14667 14667 14667 14667 14667 14667 Narrowband: E1 Qty. for CCS7 Link 22 22 22 22 22 22 22 22 Narrowband: External E1 Qty. 612 612 612 612 612 612 612 612

3.5 System Configuration

The following table give the specification and performance: of hardware used in this project :

HW Type Specification Description

ATAE Frame

Each ATAE frame includes 2 pieces of fixed switch boards and maximum supports 12 pieces of processing boards, each processing board includes 4C8G and 2Fabric FC&4GE

S3100 Storage Array,S3100,Maximum support hard disk 112 pcs. Each frame maximum support 16 pcs hard disk.



ATAE Board（R2） cal l handling capability

cal l handling capability(Considering DR loss)

cal l handling capability(Cosidering DR loss+Hot Standby loss)

ATAE(TPS of each processing board-R2)

14,000 11,667 10,606

SCP(CAPS of each processing board, only considering voice call processing)

933 778 707

CBP(CAPS of each processing board,only considering voice call processing)

700 583 530

3.5.1 Central Site

ATAE Board Y1 Y2 Y3 OCS-SCP 34 34 34 OCS-CBP 74 74 74 CBP-DB 16 16 16 OCS-BMP 8 8 8 OCS-FEP 2 2 2 OCS-RBI 2 3 5 OCS Bill server 0 0 0 OCS OAM 1 1 1 I2000 2 3 4 OCS-REPORT 1 1 2 UVC-VCP 4 6 8 UVC-VMP 4 8 10 UVC-FEP 0 2 2 UVC-Web server 2 2 2 Test bed 3 3 3 Total 153 163 171

3.5.2 Site2/3/4/5/6 are same

ATAE Board Site 2/3/4/5/6 OCS-SCP 34 OCS-CBP 74 CBP-DB 16 OCS-BMP 8 OCS-FEP 2 OCS-RBI 2 OCS Bill server 0 OCS OAM 1



I2000 1 OCS-REPORT 1 UVC-VCP 0 UVC-VMP 0 UVC-FEP 0 UVC-Web server 0 Test bed 0 Total 139

3.6 Physical Parameter of Hardware

Type Depth (mm)

Width (mm)

Height (mm)

Power （W）

Heat dissipatio

n

Max Weight（Kg）

ATAE Frame 420 436 619.5 2490 8,028BTH/Hour 105

Storage-S3100 563 447 130.3(3U) 446 1,438 BTH/Hour 30



3.7 Rack layout and footprint

Phase Central

(Y1) Site2 (Y1)

Site3 (Y1)

Site4. (Y1)

Site 5 Site 6 UVC DR Depth (mm)

Width (mm)

Height (mm)

Weight (kg)

Y1 20 20 0 0 0 0 1 1000 600 2200 200

Y2 add 1 0 20 20 0 0 1 1000 600 2200 200

Y3 add 0 0 0 0 20 20 0 1000 800 2200 150

3.8 Bandwidth for DR

Usage Ratio 0.7 If Cable 40%, If Fiber 70%

SCP CAPS 23955

CBP CAPS 27546

SCP (M) 27 0.1 *1024 * SCP CAPS/Usage Ratio*8/1024/1024

CBP (M)

Physical DB 62 4*1024*0.05* CBP CAPS *8/Usage

Ratio/1024/1024

Memory Delta 200 (2659/4) * CBP CAPS *8/Usage Ratio/1024/1024

BMP (M) 17 4*1024 * BMP CAPS * 8/Usage Ratio/1024/1024

1000000 Sub 16 CAPS

20000000 Sub 366 CAPS

SUM of

Bandwidth 306 Megabytes



4 Glossary

AoC Advice of Charge

ATM Automatic Teller Machine

APRU Average Revenue Per User

BMP Business Management Point

BSS/OSS Business and Operation Support System

CBCP Convergent Billing Configuration Point

BHCA Busy Hour Call Attempt(s)

CAPS Call Attempts Per Second

CC Customer Care

CDR Charging Data Record

CRBT Colorful Ring Back Tone

CRM Customer Relationship Manager

CP Content Provider

CoS Class of Subscriber

DCC Diameter Credit Control

EJB Enterprise Java Beans

FNS Familiarity Number Service

GPRS General Packet Radio Service

IMS IP Multimedia Subsystem

MDSP Mobile Data Service Platform

MML Man Machine Language

MMS Multimedia Messaging Services

MVNO mobile virtual network operator

NE Network Element

OCS Online Charging System

PCS Pieces

POS Point Of Sales

POM Point Of Management

SCP Service Control Point

SMP Service Management Point



SMS Short message Service

SP Service Provider

SOAP Simple Object Access Protocol

USSD Unstructured Supplementary Service Data

VPMN Virtual Private Mobile Network

TELLIN One Brand of Huawei

•

tellin ocs technical proposal for ttsl

Documents

ocs scp

huawei ocs solution

huawei ocs brief

focus of huawei ocs

activeactive dr

cbp dr switching

system architecture

tata huawei technologies