Huawei TELLIN CRBT

Technical Proposal
for AXB









April, 2010

Table of Contents
1 Overview ....................................................................................................... 4
1.1 Project Overview ...................................................................................................... 4
1.2 Solution Overview .................................................................................................... 4
1.3 AXB CRBT Network Topology after expansion .................................................... 5
1.4 3M H/W Centralized IP based CRBT solution .................................................... 5
1.5 3M URP Solution (3M for centralized IP based CRBT) ..................................... 6
1.6 USDP Service Management Platform Overview .................................................. 6
2 Huawei TELLIN CRBT Value Proposition .................................................. 7
2.1 Abundant Application and Large Capacity ............................................................ 7
2.2 Rich Experience on Interconnecting with MSCs ................................................... 7
2.3 Carrier-grade CRBT System................................................................................... 7
2.4 Rich Service Features ............................................................................................. 7
2.5 Global Presence serves you anytime, anywhere .................................................. 7
3 CRBT Solution Proposal ............................................................................. 8
3.1 Solution Overview .................................................................................................... 8
3.1.1 Networking Architecture .............................................................................................. 8
3.1.2 RBT Trigger and Routing ............................................................................................ 8
3.1.3 CRBT Signaling Flow .................................................................................................. 9
3.2 CRBT provisioning ................................................................................................. 10
3.2.1 CRBT provisioning flow in MSC-based solution ...................................................... 10
3.3 CRBT Charge Solution .......................................................................................... 13
3.3.1 CRBT charging flow ................................................................................................... 13
3.4 Requirement ........................................................................................................... 16
3.4.1 Requirement for O-MSC ............................................................................................ 16
3.4.2 Requirement for HLR ................................................................................................. 17
3.4.3 Requirement for Billing .............................................................................................. 17
3.5 CDR Specification ................................................................................................. 17
3.6 I2000 System of TELLIN CRBT ........................................................................... 17
3.7 The End to End Solution of CRBT ....................................................................... 18
3.8 From 2G to 3G ....................................................................................................... 20
3.9 Introduction of TELLIN CRBT system .................................................................. 20
3.9.1 Logical architecture .................................................................................................... 20
3.9.2 Platform Description .................................................................................................. 22
3.9.3 Platform Reliability ..................................................................................................... 27
3.10 Service Features .................................................................................................... 28
3.11 Service provisioning and charging ....................................................................... 28
4 Equipment Dimensioning ......................................................................... 28
4.1 CRBT Calculation for Full IP Based ..................................................................... 28
1.1.2 List of Service Requirement and Traffic Data .......................................................... 28
1.1.3 Calculation result ....................................................................................................... 29
4.2 CRBT Calculation for Upgrade the Existing System .......................................... 32
1.1.4 Power Requirements ................................................................................................. 32
5 Glossary ..................................................................................................... 33
6 Appendix I .................................................................................................. 34

1 Overview
1.1 Project Overview
This document is the technical proposal for the provision of a TELLIN

CRBT system
to AXB by Huawei Technologies Co., Ltd. (hereinafter referred to as HUAWEI).

Huawei has comprehensively understand AXBs existing CRBT solutions
challenges::
1. The existing V5.0 CRBT (deployed in 2005) is constructed based on the HP platform.
V5.0 platform can not provide the more diversity features to meet the markets
need. HP Hardware has expired as well as maintenance cost is getting higher.


2. The CRBT service in AXB is growing very quickly so that the capacity needs to expand.

3. The existing AIP is dedicated in narrow board processing, It cant meet the futures IP
trend solutions need.

According to this,. Huawei proposes a centralized solution to meet the AXBs
requirements: This centralized solution aims at the following key points:

1. Upgrade the existing V5.0 CRBT software platform to V6;
The proposed V6 is able to provide excellent features to attract more customers
and Increase AXBs ARPU.
.
2. In this project , According to AXBs request , Huawei proposed 1M Hardware and software
expansion,1M Hardware swap from HP to ATAE as well as the platform software
upgrade from V5 to V6.


1.2 Solution Overview
A complete CRBT solution consists of two major parts. One is service trigger and the
other is service platform.
Service trigger is to realize how to establish the voice trunk connection with service
platform when the called party is a CRBT subscriber. As for a CRBT call, the network
will identify the called party is a CRBT subscriber and then build connection with the
service platform to play CRBT to the calling party. We propose CRBT trigger solution
as the proper one and introduce it with details in section 3.2 below.
Service platform is where functions are provided. It mainly provides playback of CRBT
to calling party, service features, service subscription and service charge. Huawei
provides TELLIN CRBT system as the service platform in the proposed solution.

1.3 AXB CRBT Network Topology after expansion

1.4 3M H/W Centralized IP based CRBT solution
Following is the Proposed Centralized IP based CRBT solution architecture :

This is a new ATAE solution to take over the old HP platform , Management node and
Call node will be Centralized in Uday;

1.5 3M URP Solution (3M for centralized IP based CRBT)
For the CRBT , Both of the voice channels and signaling channels are conveyed by IP.
The BICC capacity subscriber is 3M , and signaling type will be BICC, software capacity
is 2M;

The main parameters based the traffic model are figured out as following.
The 3M CRBT traffic parameter is in the following :
No. Item 2M Subscribers Capacity for URP
1 BICC Msg. Qty. per second 3675
2 N-Band VP Chanel Qty. BICC 12960
3 RBT Call CAPS (BICC) 500
4 Management Call CAPS (BICC) 25
5 Signaling Bandwidth 21.03Mbps
6 Voice Bandwidth 819.75Mbps

All the MSC should have capability to read SS_Code data in SRI_Response and trigger
split IAM. For the internal flow in CRBT system, the load balance will judge which server
will deal with the CRBT request.

1.6 USDP Service Management Platform Overview
In TELLIN CRBT system, the service management and operation platform adopts
open and loosely-coupled structure. It consists of three layers including USDP
Platform, USDP API and Application Software from bottom to up.
USDP Platform implements all the service logics and is the running platform. It also
provides to interconnect with IN/Billing systems for charging functions. Based on
USDP Platform, the service logics are encapsulated into USDP APIs. These APIs
adopt SOAP protocol which are international open standard and easily used for
development. The top layer is Application Software which is developed with USDP
APIs and it contains WEB/SMS/IVR/etc portals & enhanced features.
Through this open structure, it can bring following major benefits for AXB:
Besides Huawei, AXB or other third parties can also be engaged to develop user
interfaces easily with APIs.
Improve the responding time for the customization of user interface.
Easily make new access available to the CRBT service.
If it is SP to build the user interface, SP can promote CRBT service together with
AXB.
2 Huawei TELLIN CRBT Value Proposition
2.1 Abundant Application and Large Capacity
Huawei started CRBT service R&D since 2002 and launched the first commercial site
in China Mobile Shanghai on 17th May, 2003. Till now Huawei TELLIN CRBT system
has been selected by more than 40 AXBs such as China Mobile in China, AIS in
Thailand, MEGAFON in Russia, EMTEL in Mauritius, OI in Brazil, OPTIMUS in
Portugal etc in more than 30 countries. The total capacity of Huawei contract CRBT
worldwide has reached 100 million by Sep. 2005..
As Huawei has cooperated with so many AXBs, the rich experience can also help
Huawei to fulfill this project successfully.
2.2 Rich Experience on Interconnecting with MSCs
Huawei TELLIN CRBT system has already interconnected with MSCs from most
major vendors that include Ericsson, Nokia, Alcatel, Siemens, Nortel, Lucent etc. It
provides Huawei rich experience to handle variety of network situation and propose
most suitable solution for AXB.
2.3 Carrier-grade CRBT System
CRBT is the first content related voice service ever involved in the call flow. This kind
of involvement fundamentally differentiates CRBT service from other traditional IVR
services. IP is the core module of any CRBT system, as it directly interconnects with
MSC. This requires IP to be as reliable and steady as the tandem MSC. And unlike
other IVR service, CRBT is call related service, so that it also requires the IP to have
massive exchange ability and carrier-grade stability.
Huawei TELLIN CRBT system is designed based on Huawei NGN softswitch.
Therefore, carrier-grade reliability is ensured by Huawei CRBT system.
2.4 Rich Service Features
Beside carrier-grade hardware platform, Huawei TELLIN CRBT system also provides
rich service features: WEB/IVR/SMS portal, caller-based CRBT, time-based CRBT,
caller group management, personal library, period of validity etc.
With these abundant features, it can make AXBs CRBT service more competitive,
easily used and more interesting so that it can attract more subscribers.
2.5 Global Presence serves you anytime, anywhere
8 regional headquarters, 55 branch offices outside China with 3-level customer
service system (HQ, Regional, local) guarantee the most effective and timely
technical support for deployment and maintenance of the whole system.
3 CRBT Solution Proposal
3.1 Solution Overview
3.1.1 Networking Architecture


The signaling between MSC and CRBT are BICC protocol based IP network, to
support the called party recognition on calling party switch, the network entities of
different MSCs should have capability of reading SS_code from SRI response
message and should be able to trigger split_IAM.

3.1.2 RBT Trigger and Routing
The RBT solution can support intelligent user and non-intelligent user.
Register RBT subscribers SS_CODE(254) in HLR.
When A call B, VMSCa will send SRI to HLR to get SS_CODE(254) of B.
VMSCa will find that B is RBT subscriber and route the call to VMSCb.
First VMSCb pages the called party, if the status is idle, VMSCa will originate a
leg to connect RBT platform with prefix. Afterwards RBT platform plays the back
tone of B to calling party.
If called party answers, VMSCa will disconnect the link to RBT platform. Then the
calling party and called party can communicate.
3.1.3 CRBT Signaling Flow
The O_MSC Server receives a call request from the caller, and then queries
for the called roaming address and obtains the RBT subscription information
of the called party.
The O_MSC Server routes the call to the T_MSC Server based on the
roaming number.
After paging the called party, the T_MSC Server instructs the phone of the
called party to ring and sends a notice to the O_MSC Server if the called
party is idle.
The O_MSC Server initiates a call to the URP.
The URP triggers the RBT flow and plays the RBT specified by the called
party to the O_MSC Server.
The O_MSC Server transparently transmits the RBT to the calling party.
After the called parity picks up the phone, the O_MSC Server releases the
call to the URP.
The conversation begins.



















3.2 CRBT provisioning

3.2.1 CRBT provisioning flow in MSC-based solution
MSC-based solution is the solution to upgrade MSC & HLR to provide triggering method for CRBT service. Normally
SS_CODE is used to mark the attribute of RBT service in HLR. The detail case by case provisioning and charging
description will be available in Apendix I.

Network diagram
OSS
CRBT
HLR
CRM
WEB/IVR/
SMS
Interface III
Interface I
Interface II

CRBT provisioning system provides several convenient ways for end user to subscribe or unsubscribe CRBT service,
for example: CRM system, WEB/IVR/SMS etc. This diagram shows that all the related entities in the CRBT
provisioning flow. There are 3 entities and 3 interfaces.
The 3 related entities are explained as follows:
HLR --- to store information (include CRBT service flag) of RBT user
OSS --- to provide interface between CRBT system and HLR
CRBT --- to provide CRBT service

The 3 related interfaces are explained as follows:
Interface I --- provided by CRBT to OSS, usually it is HTTP messages.
Interface II --- provided by OSS to CRBT, usually it is CDR or HTTP messages.
Interface III --- provided by HLR to OSS, it is private interface provided by HLR vendor.

The line arrow identifies the direction of message through that interface.
CRBT will only provide the interface between OSS and CRBT system. Its OSS responsibility to interactive with other
devices (e.g. HLR).
Starting from CRM system--- real-time
1. Subscribe flow
OSS
CRBT
HLR
CRM
2
1

When end user goes to business hall or dials the number of call center, he/she requests to subscribe to CRBT service,
the provisioning flow as follows:
OSS firstly accepts the request from CRM system, and OSS will invoke
HTTP API (Interface I) to request CRBT to subscribe CRBT service for
end user. When OSS invoke the subscribe HTTP API, OSS must pay
attention to the parameter: usertype, it is important to CRBT system.
After CRBT finish the operation successfully, OSS need to send mark request
(Interface III) to HLR.
In this flow, all the interfaces should work in real-time.

2. Unsubscribe flow--- real-time
OSS
CRBT
HLR
CRM
1
2

When end user goes to business hall or dials the number of call center, he/she requests to unsubscribe to CRBT service,
the provisioning flow as follows:
OSS firstly accepts the request from CRM system, and OSS will send
unmark request (Interface III) to HLR.
After HLR finish the operation successfully, OSS will invoke HTTP API
(Interface I) to request CRBT to unsubscribe CRBT service for end user.
In this flow, all the interfaces should work in real-time.
Starting from CRBT system --- real-time
OSS
CRBT
HLR
WEB/IVR/
SMS
1
2

Using IVR/WEB/SMS etc methods, end user can subscribe/unsubscribe CRBT service, the provisioning flow as
follows:
CRBT system accept users request firstly, and then CRBT system will send
HTTP request (Interface II) to OSS.
After receiving the request, OSS will deal with end users request and send
mark/unmark request (Interfaces III) to HLR.
Then OSS returns the success response to CRBT. CRBT will finish the
subscribe/unsubscribe flow. In subscription flow, OSS must pay attention
to the parameter: usertype, it is important to CRBT system.

Exception dealing
For any exception, OSS needs to send rollback request to the related entities before the exception point, for example:
When end user goes to CRBT system by IVR/WEB/SMS etc, he/she requests
to subscribe/unsubscribe to CRBT service
CRBT system send request to OSS
OSS will send mark/unmark request to HLR, but HLR isnt working
normally, e.g. time out to response, or return failure code.
So OSS should rollback all the processes which was completed before, and return failure
code to CRBT system.


3.3 CRBT Charge Solution
3.3.1 CRBT charging flow


Charging feature is providing a way for CRBT system to charge the subscriber based on the user type (Prepaid or
Postpaid) including charging based on download or monthly fee of CRBT function.
Network diagram


CRBT subscriber can download songs through SMS/WEB/IVR etc. This diagram shows that all the related entities in
the CRBT charging flow when CRBT subscriber downloads songs. There are 3 entities and 2 interfaces.
The 3 related entities are explained as follows:
OSS/RBI --- to provide non-real-time charging functionality for postpaid
subscriber
CRBT & Charge-GW --- to provide CRBT service. This device which
usually been used to provide charge interface with external entities, such
as OSS or IN.
IN --- to provide real-time charging functionality for prepaid subscriber

The 2 related interfaces are explained as follows:
Interface I (CDR) --- between Charge-GW and OSS, usually it is CDR.
Interface II (HTTP) --- between Charge-GW and IN, usually it is MML
protocol.


Charging flow
Charging flow for postpaid subscriber
Comment [W1]:


When postpaid subscriber download songs, the charging flow as follows:
The CRBT system will write CDR for charging a post paid user. The format
of CDR is as attached below.


Charging flow for prepaid subscriber

When prepaid subscriber download songs, the charging flow as follows:
CRBT system should charge for users download operation before
downloading songs to his personal library, so CRBT system will send
MML request to IN to deal with charging operation.
Check CDR for pre paid users
CRBT can also write a check CDR for the pre paid users. After IN charging is successful, CRBT will record the
charging information in CDR and this can be ftpd to RBI for reconciliation.

Identification of pre paid and post paid users
The CRBT system will identify if the user is pre paid or post paid based on number segment concept. That is, IN the
CRBT system, we can configure the MSISDN segment which belongs to pre paid numbers and the number segment
which belong to post paid users. Based on this, CRBT system will send correct charging request.

Monthly fee charging:-
In the current system, month fee is calculated by IN. In the new solution, IN
will not calculate month fee.
RBT will calculate when to charge the user month fee from next month
onwards.
Comment [W2]: USDP MMLIN
SMP
Comment [W3]: USDP check CDR
IN
Comment [W4]: New solution
IN
When a pre paid user is eligible for month fee collection, RBT will send a
MML request to IN.
When a post paid user is eligible for month fee collection, RBT will write
CDR.

Monthly fee model:-
In CRBT system we can configure the length of a billing cycle. So if we configure the
billing cycle day as 7, the system will behave as follows.

If the third charge try also fails, the user will be unsubscribed from the system. The number of
retries can also be configured.



3.4 Requirement
3.4.1 Requirement for O-MSC
Following the requirement for O-MSC
1. It can distinguish whether the call is RBTs call, according to the SS_CODE(254)
in HLR.
2. It should support BICC protocol.
For RBTs call, it should
3. First it pages the Called Party, if the status isnt idle, it will play the corresponding
voice and release the call. Otherwise, just to continue.
4. If the status is idle, it will originate a leg to link the RBT platform, and RBT
platform plays the back tone to the calling party.
5. When the called party answers, it will disconnect the link to RBT platform.
Comment [W5]:
6. When O-MSC connected to RBT system, bi-direction voice channel should be
provided so that RBT platform can get user key pressing.
7. All the MSCs and GMSCs have been upgraded to be able to support BICC
protocol.
8. Terminated MSC should provide information for call waiting, call forwarding,
announcement, so that the RBT system can distinguish all this case to do special
operation.
9. MSC deal with all the charging for the call originated from POS subscriber or
terminated to POS subscriber.
3.4.2 Requirement for HLR
HLR should save SS_CODE(254) for RBT subscriber.
3.4.3 Requirement for Billing
1. The Billing system should charge the Postpaid subscriber for the CRBT service
according to CRBT CDR.
3.5 CDR Specification
RBT CDR bills are generated by USDP. Different bill type has different structure, and
the bill type is recognized by the first several letters of bill file name.

3.6 I2000 System of TELLIN CRBT
I2000 is used to handle each elements such CRBT system and provides the following
function.
Uniform topology management
The devices and structure of the entire network are displayed in the topology
view.
The topology view provides the entrance for maintaining and managing the
NEs.
Rich configuration management
The I2000 provides the function of querying for and modifying the following
data:
Software configuration
Hardware configuration
Service configuration
Traffic
Overall performance analysis
Comment [W6]: ACM
ACM

Comment [W7]:
The I2000 provides the function of collecting and displaying the performance
data and the performance alarm; thus, the users can understand the system
running in time.
Centralized fault management
The I2000 monitors the alarms of the entire network in real time, supports the
sound and light alarms, and informs the users in various modes.
Powerful security management
The I2000 provides the secure and reliable policies for the following:
Authorizing and authenticating users and user groups
Encrypting the password
The I2000 is located at the NE management level, all the NE management level
systems provided by Huawei such as CRBT, SMSC, MMSC, MDSP, WISG, IN and so
on, can be handled by I2000.
The I2000 provides the interface for the connection of the NMS (Network
Management System) via SNMP protocol. NMS is higher level system compared with
I2000.
The following figure shows the architecture of I2000 for AXB.


Because AXB has already had I2000 server, so for the new added system, such
CRBT, MMSC and WISG, only license is necessary, which is used to get permission
to be handled by I2000.

The existing i2000 server is V440 2CPU (1.28GHZ) and 4G Memory, which can
handle about 700 NE(network elements).
3.7 The End to End Solution of CRBT
The current architecture is shown as follows,

For MGW/MSC01: 4*E1 for signaling, 46*E1 for voice channels;
For MGW/MSC02: 8*E1 for signaling, 80*E1 for voice channels;
For MGW/MSC03: 4*E1 for signaling, 45*E1 for voice channels.

After Upgraded by URP, the physical connection between URP and MGW/MSC is based
IP network. The follow figure shows the architecture. Actually, the middle equipment is the
centre router between URP and MGW/MSC.

Because all the MGW and MSC will be upgraded to IP supported, the MGW and MSC
will be connected with the centre router by IP network also.

The previous T-MSC will become the pure Trunk MSC without any MGW, so the only
one MSC is proposed to connect with CRBT, which is G-MSC with MGW. All the
signaling channels will connection with G-MSC, while all the voice channels will
connect with the MGW.

The bandwidth between URP and MSC is 21.03Mbps;
The bandwidth between URP and MGW is 819.75Mbps.

3.8 From 2G to 3G
The solutions of CRBT system is completely IP based, the protocol for CRBT is BICC.

For the current application and services, whatever 2G supports, 3G can also support.
However, if there are new types of service requirement, for example, video RBT,
some additional hardware such as multimedia boards which support video service
and video interface gateway (VIG) will be needed.

Another example is Video Conference Service, which is a popular service provided in
3G network. Since this is a new type of service compared with the current IN
application, additional hardware, software and protocol for this service are necessary,
which will lead to additional cost.

All in all, the current features of CRBT if provided in 2G network will be supported in
3G network totally.

3.9 Introduction of TELLIN CRBT system
3.9.1 Logical architecture
Following is the logical architecture of Huawei TELLIN CRBT system, it contains
switching module, call control server, user profile, content library and service
management and operation platform. And they will be introduced one by one in
section 3.3.2.

TELLIN CRBT system Logical Architecture

TELLIN CRBT Management Site
CRBT call process flow
To process a normal CRBT call, the interaction between each module of Huawei
TELLIN CRBT system is as follows:
MSC sends IAM to switching module. After processing IAM, switching module returns ACM/ANM
and then sends a request to call control server through TCP/IP.
Call control server translates the received message and invokes the call process logic, then it will
send request with MSISDN of calling party and called party to user profile to query content ID.
User profile returns the related content ID. And it is returned to switching module by call control
server.
After getting the content ID, switching module checks its cache firstly, if the related content is
already there, it will plays it to MSC directly.
Otherwise switching module sends request with content ID to content library to query the related
content file.
After getting content file returned from content library, switching module plays it to MSC.
3.9.2 Platform Description
The Signal and Switching Module in CRBT system is also called URP8100 (Universal
Resource Platform). It provides the service trigger, signaling transparent transmission,
signal tone detection, and call out functions of the CRBT service.
The URP8100 contains two parts: Media Gateway Controller (MGC) and the Media
Gateway (MGW). URP8100 MGC consists of the call control and media resource
component. The following figure shows the structure of the URP8100.

Structure of URP8100
a. MGC
The MGC is the call control and media resource part of the URP8100, and is the
crucial part. Its hardware is developed based on Huawei Open Standards Telecom
Architecture (OSTA) platform and its software is developped based on Distributed
Object-oriented Programmable Realtime Architecture (DOPRA) platform
Hardware
Physically MGC is composed of two parts. One is OSTA frame that forms the host of
URP8100 MGC, providing the functions of service processing and resource
management. The other is Back Administration Module (BAM) that builds up the
background of URP8100 MGC, offering the OAM functions.
Software
The software system of MGC is composed of host software and terminal Operation
and Maintenance(OAM) software
The host software runs on the main processor of MGC and is designed to provide
functions including signaling and protocol adaptation, call processing, service control,
media resource management, media resource processing
The terminal OAM software runs on the BAM and the workstations, along with the host
software, it supports maintenance personnel to implement the following functions on
the host including data management, equipment management, alarm management,
performance measurement, signaling trace

b. MGW
The MGW is the TDM switching centre of the URP8100. It has a TDM switching
capacity of 256K.
Hardware
Classified by functions there are four types of frames in MGW. The first one is main
control frame that manages and maintains the entire equipment and accesses and
processes services. The second one is service frame that provides the service bearer
processing function. The third one is central switching frame that provides multi-frame
cascading function when there are more than three frames. The fourth one is
extended control frame that provides connection management and control function
only, not any bearer service access or processing function. It is configured only in full
configuration of the URP8100 MGW.
Software
The MGW software system consists of two main parts: Host software and Client
software.
The host software is responsible for bearer service processing, lower-layer base
software and hardware management. The Client software and BAM module of the
host software, esigned in client/server infrastructure, are responsible for routine
maintenance and management of the host machine.

The URP8100 has following main features:
I. Abundant Media Resource Capabilities
The URP8100 can provide rich narrowband resources for PSTN and PLMN, and rich
broadband media resources for NGN and 3G networks. The resources include:
Receiving and sending Dual Tone Multi-Frequency (DTMF) signals
Sending signal tones
Detecting signal tones
Sending record announcement
Recording
G.711/G.729/G.726/G.723 voice codec
In addition, the URP8100 provides functions such as subscriber interaction script,
dynamic loading and management of media resources, and multi-lingual support.

II. Large Capacity and High Integration
Large capacity
At the full configuration, the URP8100 supports:
BHCA of 8,000k
256K switching capacity.
38,400 narrowband or broadband media resource channels and 60,480 TDM
trunks at the same time.
High integration
Each board can provide
240 narrowband channels
Or 240 broadband channels
Or two STM-1 optical interfaces of 126 E1
III. High Security
To ensure the security of the network and all valid subscribers, the URP8100 equips a
perfect security design against malicious attacks, illegal registrations, anonymous
calls, wiretapping, stealing accounts and other illegal acts.
Security Data
Backs up data between active boards and standby boards in real time.
Automatically backs up of the database of the active processing unit to a flash
memory.
Security in the Aspect of Operations and Maintenance
Verify both account and IP address in login.
Manages multiple levels of subscriber authority.

IV. Excellent Performance Measurement Functions
The URP8100 provides excellent performance measurement (PM) functions, and
supports many PM entities and customized PM tasks. The URP8100 uses lists and
graphics to display the performance data in real time to fully reflect the traffic load
status and the operation of itself.
Several traffic measurement items can be combined according to your requirements.
Items can be measured individually or together at a time.

V. Convenient and Practical Operation and Maintenance
The URP8100 provides convenient and practical operation and maintenance (OAM)
functions as follows:
Flexible and Diversified Management Modes
The terminal system of the URP8100 works in a distributed Client/Server structure,
providing many maintenance modes such as Graphical User Interface (GUI) and MML.
The URP8100 can be accessed at the same time by multiple local and remote clients.
Visualized Graphical User Interface
The URP8100 provides OAM interfaces by using a unique navigation tree technology.
In this way, many MML features and GUI advantages are retained, such as visualized,
simple and quick to use, easy to access NMS, and easy to memorize. In addition, the
URP8100 provides vivid graphical network component topology view and equipment
panel, enabling visualized operation.
Optimal Call Tracing, Signaling Tracing, Interface Tracing and Message Interpretation
Functions
A software tool of signaling analysis, which is independently developed by Huawei, is
built in to offer customers with powerful fault analysis and location features.
Realtime Fault Management Capability
The system receives and displays network equipment fault report in real time, so that
the maintenance personnel can diagnose the fault source rapidly and precisely and
take proper measures to recover the system from the abnormal service.

VI. High precious clock
The URP8100 has stratum-2 and -3 clocks. It provides standard clock interfaces. It
can retrieve clock reference source from BITS, and 8-kHz E1/T1 line clock through
software control, ensuring the clock reliability of the system
1. Call control server
Call control server contains CTI/FEP server and UI server. CTI/FEP server is to
change messages of each CRBT phone call from switching module into internal
messages and transfer them to UI server. UI server is to decide which ring back tone
(content ID) should be played according to the information received.
2. User profile
All the service related user data are stored in user profile for querying by call control
logic and it adopts Oracle 9i database.
3. Content library
Content library stores all content resource being used in CRBT service providing
internal TCP/IP interface for voice resource system to query the content.
4. Service management and operation platform
1) Figure & Functions

Service Management and Operation Platform
This platform provides necessary functions for the management and operation of the
CRBT service.
End-user can use this platform to manage their personal profile. Content provider can
use this platform to upload and manage content resources. AXB can use this platform
to implement the management and operation of the CRBT service.
This platform also provides various external interfaces to offer different access for the
management as well as to integrate with billing or other back office system.
As for more details of service features, please refer to Annex A.
2) Open Software Structure Based on USDP

Service Management and Operation Platform Software Structure
The diagram above shows the three layers of the service management and operation
platform of Huawei TELLIN CRBT system.
The bottom layer is USDP Platform. It implements all the CRBT service logics and is
the running platform. It also can interconnect with IN or Billing system to charging for
prepaid and postpaid subscribers.
Above USDP Platform, it is the USDP API layer which is based on SOAP protocol.
This layer encapsulates the capability set of USDP Platform into APIs. As SOAP is an
international open standard, it is easily used for developing service.
The top layer is CRBT Application Software which provides service features including
WEB/IVR/SMS/ portals and enhanced features to end-user, AXB and CP. It is
developed through calling USDP APIs.
As these three layers are separate and independent with each other, this open and
loosely-coupled architecture will bring tremendous flexibility to the CRBT service:
a) Improve the responding time for the customization of user interfaces
User interface can be changed constantly
AXB can choose to let Huawei to provide some accesses like IVR/SMS/WEB
and by itself or with the help of third party to develop other accesses like
WAP/USSD etc.
b) Easily make new access available to the CRBT service
When new access technology (for example - i-mode) come out in the future,
CRBT service platform can support this new access without any modification
c) If SP can build the user interface, SP will be able to promote the service together
with AXB.
In this project, based on AXB requirements, Huawei will provide USDP Platform and
portals including WEB accesses.
3.9.3 Platform Reliability
1. Platform Redundancy
Power supply, signaling link and network equipments have backups to avoid possible
single-point fault.
The URP8100 adopts active/standby mode, load sharing and redundancy configuration
for the boards; optimizes fault detection and isolation techniques of the boards and
the system to improve the maintainability of the whole system. The URP8100 adopts
a layered and modular structure with performance protection, error tolerance and
fault monitoring. The URP8100 provides four levels of overload restrictions, dynamic
code adjustment mode and traffic control to fully ensure the reliability of the system.
In CRBT system, all servers adopt HP/IBM PC server or mini-computer. If using PC server,
2 PC servers are adopted with active-standby structure or load-sharing mechanism.
If using mini-computer, the dual system can assure the high reliability.
User profile database adopts disk array that works with RAID mechanism.
Network management system HUAWEI CRBT system adopts I2000 network
management system which can be accessed through standard SNMP protocol.
I2000 monitor all units of CRBT system in real time and provides fault management
function.
1. Faults Handle
Signaling link fault
If single signaling link fault occurs, the backup one will still work and CRBT system
can communicate with MSC normally to play CRBT. If all signaling links has faults, the
MSC will detect it and revert back to the standard ring back tone.

URP fault
If single board has fault, the backup board will take over its service so that CRBT can
still be played normally. If the whole URP is down, the MSC will also detect it and
revert back to the standard ring back tone.
CRBT call processing servers and database fault
Comment [W8]: ???
If the active server fails, its work will be switched to the standby server and will not
affect playing of CRBT. If both active server and standby server has fault and make
the CRBT call processing flow fail, URP will detect it through getting no response or
failure and sends REL to release the trunk with MSC. And then MSC will play the
standard ring back tone only.
Service management and operation platform fault
If single server fails, the backup one will take over its work. If the whole platform has
fault, it will affect all service management functions like subscription, charging etc, but
it will not affect the CRBT call flow as it is not involved.
Network fault management
If any fault mentioned above occurs, it will be reported to I2000 system and raise
related alarm to inform the system administrator. And also I2000 provides to monitor
other faults of CRBT system.
3.10 Service Features
TELLIN CRBT system provides for AXB will cover all the current system features and
functions. The detail of features and functions can be referred to TELLIN CRBT
function list for AXB.
3.11 Service provisioning and charging
TELLIN CRBT system provides multi ways for end user to subscribe or unsubscribe CRBT
service. These ways includes starting from CRM or starting from CRBT system.
TELLIN CRBT system supports two kinds of service charge type. One is service monthly fee
which is charged for a CRBT subscriber each month with fixed expense. The other is fee of
purchasing CRBT which is charged for a CRBT subscriber every time when he downloads a
CRBT from the system.
TELLIN CRBT system can supports both POS subscriber and PPS subscriber. The details of
charging and provisioning are already discussed in the preceding chapters.
4 Equipment Dimensioning
4.1 CRBT Calculation for Full IP Based
1.1.2 List of Service Requirement and Traffic Data
According to the requirement of AXB, we have the following basic traffic model:
Basic Service Parameters
ITEM VALUE
BICC Subscriber 3,000,000
MSC Erl per 0.03


Service Traffic Data
Average Holding Time (s) Length of Ring Time (s)
90 20

Other Data
ITEM VALUE
BICC Msg. Qty. per Management
Flow 7
BICC Msg. Qty. per Call Flow 7
Average Length of BICC Msg. (Byte) 300
MSC-Erl per Sub 0.03
Ratio of Call flow 0.05
MHT of Management Call (S) 120
Ratio of Internet Sub. 20%

Item
3M Capacity
(OPS per second)
Value 15

This OPS (Operation per Second) is the total operation quantity per second of subscription service,
un-subscription service, management setting, management download, services active and
deactivate, RBT subscriber visiting WEB portal and non-RBT subscriber visiting WEB portal.

1.1.3 Calculation result
The following calculation is for is the calculation result.
(RBT Platform BHCA per Sub. )= ((MSC-Erl per Sub.)/MHT)*3600* (Percentage of called
traffic) =0.03/90*3600*50%=0.6
Subscriber
Called traffic per
subscriber
0.015

RBT Call CAPS (BICC)
Call CAPS = RBT Sub.Qty. * Erl (average Erl of each sub.) / MHT
=3*600000/3600 =500

Management Call CAPS (BICC)
Management Call CAPS = RBT Call CAPS * Percentage of Management Call
=500*0.05 =25
BICC Msg. Qty
BICC MSG Qty per second = Management Call CAPS * BICC Msg. Qty. per
Management Flow + RBT Call CAPS* BICC Msg. Qty. per Call Flow
=(25+500)*7 =3675
VP Channel Qty. BICC
N-Band VP Channel Qty. BICC = 120*Round(((RBT Call CAPS (BICC))* (Ring Time) +
(Management Call CAPS (BICC))*(MHT of Management))/ (Load of Internal E1 (For VP
CH.)/120))= 120*Round((500*20+25*120)/120)=12960
Signaling Bandwidth
Signaling Bandwidth (Mbps) (RBT Call CAPS+ Management Call CAPS) * BICC Msg.
Qty. per Call Flow * Average Length of Signaling Message*8/ Bandwidth signaling Utilize
Ratio /1024/1024= (500+25)*7*300*8/0.4/1024/1024=21.03
Parameter Value
Encoding Bandwidth 45.2
Bandwidth Signaling Utilize Ratio 0.4

Voice Channel Bandwidth
VP Channels Bandwidth (Mbps) = (RBT Call CAPS * Ring time + Management Call
CAPS * MHT of Management Calls) * Encoding Bandwidth * 1024/VP Channel
Bandwidth Utilize Ratio /1024/1024
VP channels Bandwidth (Mbps)= (500*20+25*120)*45.2*1024/0.7/1024/1024
=819.75
Parameter Value
Encoding Bandwidth 45.2
VP Channel Bandwidth Utilize Ratio 0.7

ATAE calculation formulas are as follows,
a, CTI/FEP: 2*Roundup (Call CAPS/800 + Management CAPS*MHT/8000)
=2*Roundup(500/800+25*120/8000)
=2

b, Portal Board Number =2*Roundup ((Busy hour OPS)/(Per Portal Capacity
OPS)*(Management Ratio))
=2*Roundup (15/60)
=2

c, USDP Board Number = 2*Roundup ((Busy hour OPS)/(Per USDP Capacity))
=2*Roundup(15/44)
=2
USDP board number has been increased to 5 to create more connections towards IN.
d, VXML Board Number = Roundup(Management CAPS*(Transaction per Management
CAPS)/Per VXML Capacity)
=Roundup(25*15/80)
=4

DB Board Number calculation
Management DB/Call DB/Report DB TPS is including Call TPS and Management TPS.
1. Call TPS
(Total subscribers)*(BHCA per sub)/3600*(transactions per CAPS)
=3000000*0.6/3600*103
=51500
Transaction per CAPS is 103.
1. Management TPS:
OPS* (Transaction per operation)
=15*2653.3
=39799.5
The OPS is 15.
Transaction per operation is 39799.5

So, the total TPS is 39799.5+51500=91299
If the TPS is less than 95001, the DB board number is 2.
But DB board number has been increased to 7 to cater enhance features and to co-host
report server.

The following table is the calculation result.
No. Item For 2M Centralized
1 FEP/CTI ATAE 2
2 Portal ATAE 2
3 VXML board 2
4 USDP ATAE 5
5 Management DB/Call Processing
DB/Report DB
7
6 Call DB/Management DB
Storage
16*300Gb
7 File Server Storage (URP for
CRBT)
16*300Gb

4.2 CRBT Calculation for Upgrade the Existing System
1.1.4 Power Requirements
For the totally new CRBT platform of 3M subscribers capacity
DC Power (W)
Total 20,950
CRBT 1,341
URP 9,329
Rack 1,060
NE 9,220

Considering AXB required, Huawei proposal suggest that power can last 8 hour based on
the output above.

5 Glossary
URP Universal Resource Platform
CRBT Customized Ring Back Tone
CTI Computer-Telecommunication Interface
HLR Home Location Register
IN Intelligent Network
BICC Bearer Independent Call Control
IP Intelligent Peripheral
ISUP ISDN User Part
MAP Mobile Application Part
MHT Mean Holding Time
MSC Mobile Switching Center
SCP Service Control Point
SMP Service Management Point
Sub. (RBT) Subscriber
USDP Universal Service Development Platform
SP Service Provider
NMS Network Management System










6 Appendix I


Register Prepaid
Register Prepaid
Step1. Subscrlber send reglstrutlon request by sms/lvr/buslness hull
Step2. RBT system lnsert subscrlber lnfo ln RBT DB
Step3. RBT send provlslon request to OSS Agent
Step4. OSS Agent knows the correct HLR from MSISDN/IMSI serles und
sends MML commund to udd SS_code
Step5. u) HLR sends response success/fullure. lf successful RBT system
proceed
b) lf HLR provlslon fulls, RBT rollbuck, log generuted
Step6. If HLR provlslon successful RBT send churglng request to SMP (IN) vlu
churglng gutewuy
Step7. u) lf churglng full , RBT rollbuck ln HLR und RBT DB, log generuted
b) lf churglng successful then proceed to generuted CDR







Deregister Prepaid (System
Step1. Subscrlptlon fee dute urrlves for CRBT subscrlber, CRBT system sends churglng
request over MML (from churglng gutewuy to IN-SMP) for 3 consecutlve duys.
Step2. u) If churglng ls successful subscrlber next blll dute ls upduted ln CRBT DB
b) If churglng fulls for 3 consecutlve duys, then CRBT system proceed to dereglster
the subscrlber. RBT system chunges stutus of subscrlber ln DB
Step3. RBT send request to OSS Agent
Step4. OSS Agent knows the correct HLR from MSISDN/IMSI serles und sends MML
commund to delete SS_code
Step5. u) lf HLR de-provlslon fulls, RBT rollbuck, log generuted
b) lf successful RBT system generutes CDR

Deregister Prepaid (User
Step1. Subscrlber send dereglstrutlon request by sms/lvr/buslness hull
Step2. RBT system chunges stutus of subscrlber ln RBT DB
Step3. RBT send request to OSS Agent
Step4. OSS Agent knows the correct HLR from MSISDN/IMSI serles
und sends MML commund to delete SS_code
Step5. u) lf HLR de-provlslon fulls, RBT rollbuck, log
generuted
b) lf successful RBT system generutes CDR






Monthly Fee (Subscription Fee)
Process Flow for Prepaid Subscriber
Step1. Subscrlptlon fee dute urrlves for CRBT subscrlber, CRBT system sends churglng
request over MML (from churglng gutewuy to IN-SMP) for 3 consecutlve duys.
Step2. u) If churglng ls successful subscrlber next blll dute ls upduted ln CRBT DB
b) If churglng fulls for 3 consecutlve duys, then CRBT system proceed to dereglster
the subscrlber, RBT system chunges stutus of subscrlber ln DB
Step3. RBT send request to OSS Agent
Step4. OSS Agent knows the correct HLR from MSISDN/IMSI serles und sends MML
commund to delete SS_code
Step5. u) lf HLR de-provlslon fulls, RBT rollbuck, log generuted
b) lf successful RBT system generutes CDR
Deregister Prepaid (System Initiated)





CRBT Prepaid Subscriber Lifecycle
Monthly Fee (Subscription Fee) Process
Flow for Prepaid Subscriber








Prepaid Download Charging Request
sending Flow
Prepaid Subscriber Download Fee
Charging Process Flow
Step1. Subscrlber send downloud request by sms/lvr/buslness hull
Step2. RBT system sends churglng request over MML (vlu churglng
gutewuy) to IN SMP
Step3. u) If churglng ls successful, the song ls downlouded ln the
personul llbrury of the subscrlber. CDR ls generuted
b) If churglng ls not successful, the song downloud fulls.





Register Postpaid
Register Postpaid
Step1. Subscrlber send reglstrutlon request by sms/lvr/buslness hull
Step2. RBT system lnsert subscrlber lnfo ln RBT DB
Step3. RBT sends request to OSS Agent
Step4. OSS Agent knows the correct HLR from MSISDN/IMSI serles
und sends MML commund to udd SS_code
Step5. u) lf HLR provlslon fulls, RBT rollbuck, log generuted
b) lf successful RBT system generutes CDR





Deregister Postpaid
Deregister Postpaid
Step1. Subscrlber send cuncel request by sms/lvr/buslness hull
Step2. RBT system chunge subscrlber stutus ln RBT DB
Step3. RBT sends request to OSS Agent
Step4. OSS Agent knows the correct HLR from MSISDN/IMSI serles
und sends MML commund to delete SS_code
Step5. u) lf HLR provlslon fulls, RBT rollbuck, log generuted
b) lf successful, RBT system generutes CDR







Postpaid Monthly Fee flow
Postpaid Monthly Fee flow
Step1. Postpuld CRBT Subscrlber Monthly fee collectlng dute urrlves.
Step2. RBT system generutes u CDR und sends lt to Bllllng System.
Step3. Its Bllllng Systems responslblllty to do the rutlng und churglng
of CRBT monthly fee.









Postpaid Download CDR Generating
Postpaid Subscriber Download Fee
CDR Generation Process Flow
Step1. Subscrlber send downloud request by sms/lvr/buslness hull
Step2. The song ls downlouded ln the personul llbrury of the
subscrlber.
Step3. CDR ls generuted und sent to Bllllng system.