2.3.2 ZTE OCS OCU Product Description

ZTE OCS OCU
Product Description
ZTE OCS OCU Product Description
Version Date Author Approved By Remarks
V4.10 2012-08-12 Not open to the Third Party
© 2012 ZTE Corporation. All rights reserved.

ZTE CONFIDENTIAL: This document contains propriet ary information of ZTE and is not to be
disclosed or used without the prior written permission of ZTE.
Due to update and improvement of ZTE products and technologies, information in this document
is subjected to change without notice.
ZTE Confidential Proprietary © 2016 ZTE CORPORATION. All rights reserved. 1

ZSmart OCS Product Description
TABLE OF CONTENTS
1 Introduction ....................................................................................................... 5
1.1 Abbreviations ...................................................................................................... 5
2 Product Overview............................................................................................... 8
2.1 ZTE Brief Introduction .......................................................................................... 8
2.2 Standards Observed ............................................................................................ 9
2.3 ZTE Overall Features ........................................................................................ 12
2.4 ZTE Overall System Structure ............................................................................ 16
3 ZTE OCS Hardware Structure.................................... Error! Bookmark not defined.

3.1 Basic Hardware Components of the OCU ................. Error! Bookmark not defined.
3.2 Basic Hardware Components of S CU ....................... Error! Bookmark not defined.
3.3 Singnaling Interface Unit (SIU) ................................. Error! Bookmark not defined.
4 ZTE OCS Software Structure ............................................................................ 19

4.1 SCU software structure ...................................................................................... 19
4.2 OCU Soft ware Structure .................................................................................... 35
5 ZTE Concept Model .......................................................................................... 43

5.1 Product Domain ................................................................................................ 43
5.2 E vent Domain ................................................................................................... 45
5.3 Price Domain .................................................................................................... 46
5.4 Customer Domain.............................................................................................. 47
5.5 Balance Domain ................................................................................................ 48
6 ZTE Product & Offer ......................................................................................... 49

6.1 „Product Relation‟ Configuration ......................................................................... 51
6.2 „Product Service Offer‟ Configuration .................................................................. 52
6.3 „Product Offer‟ Configuration Management .......................................................... 52
6.4 „Product Offer‟ Configuration .............................................................................. 52
6.5 „Price Plan of Product offers‟ Configuration.......................................................... 54
7 ZTE Charging Proce ss and Capability ............................................................. 55

7.1 Usage E vent Charging ....................................................................................... 55
7.2 One-off E vent Charging ..................................................................................... 71
7.3 Recurrent E vent Charging .................................................................................. 74
7.4 Meters .............................................................................................................. 76
7.5 Price Plan ......................................................................................................... 79
8 ZTE Extendibility to Convergent Pre-postpaid System .................................... 81

FIGURES
Figure 1 OCS Location in the Network ....................................................................................... 9

Figure 2: ZTE Flexible Price Configuration................................................................................ 15
Figure 3 General Internal and External Relation of ZTE OCS ..................................................... 17
Figure 4 ZTE OCS System Architecture .................................................................................. 18
Figure 5 ZTE OCU Hardware Components..................................... Error! Bookmark not defined.
Figure 6 ZTE SCU Hardware Structure .......................................... Error! Bookmark not defined.
Figure 7 SCP SCM Module Soft ware Structure ........................................................................ 20
Figure 8 SMP Module Structure ............................................................................................... 29
Figure 9 ZTE OCU Front-end Arc hitecture ............................................................................... 36
Figure 10 ZXOS Framework .................................................................................................... 37
Figure 11: Demonstration of hot-backup based deployment ....................................................... 38
Figure 12 Utilization of Memory-based Mechanisms ................................................................. 38
Figure 13: Mechanism of Multiple -channel................................................................................ 39
Figure 14: Process of Dynamical Loading BizLogic Object ......................................................... 39
Figure 15 ZTE OCU Functional Package .................................................................................. 40
Figure 16 ZTE Conc ept Mode.................................................................................................. 43
Figure 17 Domain Products: Actors Relation ............................................................................. 44
Figure 18 Domain E vent: Actors Relation ................................................................................. 45
Figure 19 Domain Pricing: Actors Relation ................................................................................ 46
Figure 20 Domain Customer: Actors Relation ........................................................................... 47
Figure 21 Domain Balance: Actors Relation .............................................................................. 48
Figure 22 Static View of Product Domain.................................................................................. 49
Figure 23 ZTE Usage E vent Charge Process ........................................................................... 55
Figure 24 Example of Definition of E vent Attributes in ZTE* ....................................................... 57
Figure 25 3 P hases to Support Execution of Rating Rules in ZTE Rating Engine ........................ 58
Figure 26 Example of ZTE Preproc essing Configuration* .......................................................... 58
Figure 27 Example of Defining a step of preprocessing flow* ..................................................... 59
Figure 28 Example of ZTE ZONE MAP Element* ...................................................................... 60
Figure 29 Example of ZTE Rating Paramet ers*......................................................................... 61
Figure 30 One E vent More Than One Charge* ......................................................................... 62
Figure 31 Example of ZTE Price Calculation Methods* .............................................................. 63
Figure 32 Example of ZTE Rank Price Configuration* .............................................................. 65
Figure 33 Example of ZTE Bonus Configuration* ...................................................................... 67
Figure 34 Example of ZTE Benefit Configuration* ..................................................................... 68
Figure 35 ZTE One-off E vent Charge Process ......................................................................... 72
Figure 36 ZTE Recurring E vent Charge Process ...................................................................... 74
Figure 37 Example of ZTE Accumulation P rice Configuration* ................................................... 78
Figure 38 Example of ZTE Accumulation Trigger Configuration* ................................................ 78
Figure 39 ZTE Price Plan Elements ......................................................................................... 79
Figure 40 Overall Functional Packages of ZTE Suite................................................................. 82
TABLES
Table 1 ZTE OCU Hardware Components ...................................... Error! Bookmark not defined.

Table 2 P roduct Domain Entities .............................................................................................. 44

Table 3 E vent Domain Entities ................................................................................................. 45
Table 4 P rice Domain Entities .................................................................................................. 46
Table 5 Customer Domain Entities ........................................................................................... 47
Table 6 B alance Domain Entities ............................................................................................. 48
Table 7 concept model mapping with physical model ................................................................ 51

1 Introduction
1.1 Abbreviations
AAA Authentication Authorization Accounting
AoC Advice of Charge
APN Access Point Name
BCF Bearer Charging Function
BSS Business Support System
CAMEL Customized Applications for Mobile Network Enhanced Logic
CAP CAMEL Application Part
CCA Credit Control Ans wer
CCG Cont ent Charging Gateway
CCR Credit Control Request
CDF Charging Data Function
CDR Charging Data Record
CG Charging Gateway
CP Cont ent Provider
CS Circuit Switched
CSI CAMEL Subscription Information
CSIP Convergent Service Interface Processor
CSCF Call Session Control Function
CSR Customer Servic e Representative
CTF Charging Trigger Function
CUG Closed User Group
DCC Diameter Credit Control
EBCF E vent Based Charging Function
ECF E vent Charging Function
RFP Nr: GNP RFP 001/43/09 2010 GSM Network Equipment Expansion for MTN Group 5
EMPP Extensible Messaging and Presence Protoc ol
FR Formatting and Routing
FTAM File Transfer Access Management
FTP File Transfer Protoc ol
GGSN Gateway GPRS Support Node
GMLC Gateway Mobile Location Center
GPRS General Packet Radio Service
GUI Graphic User Interface
HLR Home Location Register
HTTP Hypertext Trans fer P rotocol
IDR Interim Detailed Record
IEC Immediate E vent Charging
IN Intelligent Network
IMS IP Multimedia core network Subsystem
IMSI International Mobile Subscriber Identity
INMI Integrated Network Management Interface
IP Internet Protocol
ISMP Integrated Service Management Platform
ISC IMS Service Control
ISDN Integrated Services Digital Net work
ISMP Integrated Service Management Platform
LCS Location Services
MML Man-Machine Language
MMS Multimedia Messaging Service
MSC Mobile Services Switching Centre
MD Mediation Device
MSISDN Mobile Station ISDN number
MAP Mobile Application Part
NE Network Element

OCF Online Charging Function
OCS Online Charging System
OCU Online Charging Unit
ODR Original Detailed Record
OLC Online Collection
OSS Operation Support System
PS Packet Switched
PDP Packet Data Protocol
PHS Personal Hand-phone System
PoC Push-To-Talk over Cellular
PDSN Packet Data Serving Node
QoS Quality of Servic e
RTSP Real Time Streaming Protocol
SAN Storage Area Net work
SCU Service Control Unit
SE Service E nabler
SID Shared Information/ Data Model
SIP Session Initiation Protoc ol
SIU Signaling Interface Unit
SBCF Session Based Charging Function
SMSC Short Message Service Center
SNMP Simple Network Management Prot ocol
SMPP Short Message Peer to Peer Protocol
SMS Short Message Service
SMTP Simple Mail Transfer Protocol
SOA Service Oriented Architecture
SP Service P rovider
SSP Service S witch Point
SDF Service Data Point

TPF Traffic Plane Function
TAP Trans ferred Account Procedure
TELNE T Telecommunication Net work
UIP Unified Interface Plat form
URL Uniform Res ource Locator
VC Voucher Center
VPN Virtual Private Network
WLAN Wireless LAN
WAP Wireless Application Protocol
WIN Wireless Intelligent Network
2 Product Overview
2.1 ZTE Brief Introduction

OCS (Online Charging System) is realtime charging system in network element level which
is recommended by 3GPP. The purpose of 3GPP OCS is to realize realtime charging in 3G
network for the various multimedia services crossing CS domain, PS domain, IMS domain
and VAS domain, and to correlate the charging attributes of bearing layer, service layer and
access layer. Besides the 3G orientation, 3GPP OCS maintains the 2G realtime charging
protocols, CAME L, and WIN MAP, INAP as well to make the network and charging
evolution to 3G and MFC seamlessly and economically.
ZTE OCS adopts 3GPP OCS arc hitecture to realize realtime charging for all services and
all networks, that is, it can serve not only the 3G network, but also the existing networks
PSTN/NGN, GSM, and CDMA. The realtime charging mechanism of ZTE can be used for
both prepaid and postpaid, which gives the operator the convenienc e of convergent
charging.
For the operat or and vendor to be aware that, OCS is an application of ICT, convergence of
Information and Communication Technology, which is the trend of the industry.
ZTE OCS design and implementation deeply benefit from more than 10 years‟ practice and
technologies of telecom and IT of ZTE. ZTE billing system and Int elligent Net work system
have been deployed in more than 40 count ries world wide. The market-proven billing
flexibility and realtime charging reliability are the most important assurance for the telecom
operation.
Figure1 shows the OCS location in the net works.
ZTE compatibly supports 3GPP Diameter Credit Control and SS7 intelligent network
protocols to implement realtime charging. For the network elements supporting SS7 CAP,
INAP or MAP, they can easily connect ZTE OCS and for the 3G net work elements, DCC is
used for their realtime charging.

Billing System
DB ZSmart OCS
DB
MSC / VLR HLR GMSC Soft switch

CSCF Switch
2G CS-Domain PSTN/NGN
IMS-Domain WAP GW SMSC MMSC
SGSN
eGGSN VAS-Domain
3G PS-Domain
Diameter Credit Control
SS7 (INAP, CAP, MAP)
CDR file
Figure 1 OCS Location in the Network
2.2 Standards Observed

ZTE OCS system conforms to related tec hnical specifications of ITU-T Q.12xx, ETSI, 3GPP,
IE TF, etc.
Diameter Series
 IE TF Internet-Draft "Diameter Credit Control Application"
 IE TF RFC 2960: "Stream Control Transmission Protocol"
 IE TF RFC 3588: "Diameter Base Protocol"
 IE TF RFC 3589: "Diamet er Command Codes for Third Generation Partnership Project
(3GPP) Release 5"
 IE TF RFC 4006: "Diameter Credit-Control Application"
3GPP OCS Series
 3GPP TS 22.115 "Service aspects; Charging and billing"
 3GPP TS 32. 200: "Telecommunication management; charging management; Charging

principles".

 3GPP TS 32.215: " Telecommunic ation management; charging management; Charging

data description for the Packet Switched (PS) domain".
 3GPP TS 32.225: " Telecommunic ation management; charging management; Charging

data description for the IP Multimedia Subsystem (IMS)".

Architecture and Principles".
 3GPP TS 32.260: "Telecommunication management; charging management; IP

Multimedia S ubsystem (IMS) charging".
 3GPP TS 32.251: "Telec ommunication management; charging management; Packet

Switched (PS ) domain charging".
 3GPP TS 32.270: " Telec ommunication management; charging management;

Multimedia Messaging Service (MMS ) charging".
 3GPP TS 32.271: "Telecommunication management; charging management; Location

Services (LCS ) charging".
 3GPP TS 32.296: "Telecommunication management; charging management; Online

Charging System (OCS ) applications and interfaces".
 3GPP TS 32. 299: "Telecommunication management; charging management; Diameter

charging application".

Data Records (CDR) fil e format and transfer".
 GPP TS 32.298: "Telecommunication management; charging management; Charging

Data Record (CDR) parameter description".
 3GPP TR 32.815: "Online Charging System (OCS ) archit ecture study".
ETSI CAMEL Phase 1 Release 1996 Series
 GSM 02.78 version 5.5. 0
 GSM 03.78 version 5.8. 0
 GSM 09.78 version 5.7. 0
ETSI CAMEL Phase 2 Series
 GSM 02.78 version 6.1. 0
 GSM 03.78 version 6.2. 0
 GSM 09.78 version 6.2. 1

 GSM09.02
3GPP CAMEL Phase 3 Release 1999 Series
 TS 22.078 version 3. 7.0
 3GPP TS 22.024: "Description of Charge Advice Information (CA I)"
 TS 23.078 version 3. 12.0
 TS 29.078 version 3. 11.0
3GPP CAMEL Phase 3 Release 4 Series
 TS 22.078 version 4. 0.0
 TS 23.078 version 4. 4.0
 TS 29.078 version 4. 4.0
 TS 23.060
INAP Recommendation
 ITUT Q.121x series INAP CS-1 recommendation
 ITUT Q.122x series INAP CS-2 recommendation
MAP Related Standards
 GSM 09.02 version 7.1. 0
 3GPP TS 29.002 version 3.12.0
 3GPP TS 29.002 version 4.7.0
 3GPP TS 29.002 version 6.6.0
SS7 Related Standards
 MTP: ITU-T recommendations Q.701-Q.710 and Q.781-Q.782
 SCCP: ITU-T recommendations Q.711-Q.716 and Q.786
 TCAP: ITU-T recommendations Q.771-Q.775, Q.787
Other Standards
SMPP

 SMPP 3.3/3.4
HTTP
 http://www. w3.org/Prot ocols/
XML
 http://www. w3.org/ TR/REC-xml
WSDL
 http://www. w3.org/ TR/ws-desc-reqs
 http://www. w3.org/2002/ ws/desc/wsdl12-primer
 http://www. w3.org/ TR/wsdl12
 http://www. w3.org/ TR/wsdl12-bindings
 http://www. w3.org/ TR/ws-desc-usecases
SOAP
 http://www. w3.org/ TR/SOAP
2.3 ZTE Overall Features

This section briefly introduces ZTE OCS from the as pects as follows: design principle,
conceptual model, data model, and product features.
2.3.1 Truly Convergent Platform
ZTE OCS is a truly convergent system based on bottom-up design, and surely accelerates
the operators to realize market strategy and revenue growth via:
 One convergent plat form supports any service, content, networks and payment types
to lower the CAP X and OPE X, and to improve the customer‟s experience.
 One product catalogue maintains all services and offers to streamline the creation of
service bundle and promotions.
 One data model makes the customer domain, product domain, price domain, balance
domain least complexity and easiest integration.
 One unified architecture supports various deployments and provides APIs to quick
integrate with third party applications.

2.3.2 Multiple Service Convergence
According to the philosophy of ZTE, the „service convergence‟ indicates the adapt ability and
expansibility of a solution to support the existing and potential services in polymorphism
networks (e.g., PSTN, GSM, CDMA, WCDMA, TD-S CDMA, CDMA2000, WiMax and etc.).
2.3.3 Convergent Infrastructure Management
Since the telecom-technology based IN services gradually converge IT-technology,

Telecom operators are able to act as triple even quadruple play. According this trend, ZTE
OCS takes the advantages of technology ZTE IN to sustain the heterogeneous
Infrastructures.
2.3.4 Service Oriented Architecture
In order to reduce Operating Expenditures (OPE X), shorten time to market and enable agile
operation, Telecom operators have been converging their networks with borne services. In
addition, because the acquisitions among operators occur frequently, it forces operators to
do convergences in some other aspects. From software engineering point of view, Service
Oriented A rchitecture (SOA ) is a suitable approac h to address these convergence related
issues, so BSS and OSS venders encapsulate their products following up SOA.
Corresponding to this change, ZTE OCS employs SOA to implement the int erfaces of each
component as well, especially those interfaces exposed to external systems.
2.3.5 Unified and Independent Rating Engine
To realize its unified rating engine, ZTE adopts Object Oriented Design (OOD) to extract
features of the heterogeneous networks and servic es. This ensures the stability of the core
components, and reduces the influence of the continuously changed net works with borne
services. In ZTE, any telecom service over net works is treated as a 'product', and an
'adapter' is developed for a network protocol. Therefore, on the front-side, operators are
able to provide flexible service bundles crossing different networks according to market
demands. On the back-side, they can realize online charging, and real-time account
management.
2.3.6 Real-time Charging and Service Control
When implement ed as a true online charging system, ZTE has the characteristics as follows:
1 Real-Time Interaction With Network Element
ZTE interacts with network elements through a set of real -time, standard, and open
protocols, including DCC, SS7, SMPP, EMPP, Radius, SIP etc. A typical applicable
scenario is described as below:
i communicates with CCG, ISMP via DCC, and requests/responses AAA through
Radius
ii c ommunicates wit h all kinds of SSP via SS7 t o response the service requests
from the traditional 2G networks
iii communicates with SMS C and MMS via SMPP or EMPP

iv communicates with NGN and IMS via SIP
2 Real-time Services Control
In ZTE, the lay er of system cont rol includes the Billing Control module and the Service
Cont rol module, whic h controls the service process. The control modules for both charging
and business logic are in real-time, so the ZTE OCS can provide high-level real-time
services (e.g., balance inquiry) to north-bound systems (e.g., CRM) and south-bound
network elements (e.g. real-time charging AOC).
3 Real-time Balance Management
An important thing of service control is the balanc e management based on the real -time
charging mechanism. In ZTE, the balance management package can reserve, deduct, and
monitor balance. During the period of service consumption, ZTE res erves the balance in
terms of the specified rating strategy. Also it monitors the balance according to the pre-
defined thresholds. If the balance reaches the threshold, ZTE automatically notifies users
through the preferred channels (e.g., voice, SMS, and portal). Once the service is ended, it
calculates and deducts the balance in terms of the usage amount, success or not, and
reservation.
4 Real-time Notification
ZTE provides rich experienc e of AoC including tariff, and price plan inquire. According to
the customer profile and system configuration, AoC can be triggered at any stage (pre-
service, in-service, and post-service) of the s ervice consumption life-cycle through any
channels (e.g., voice, SMS, and portal).
5 Real-time Accumulation
ZTE allows the real -time accumulation in terms of time, byte, content and etc. Therefore it
supports multiple charging strategies and price plans based on accumulation.
Since it realizes real-time rating and service usage control, the risk of payment collection
can be significantly decreased. Furthermore, ZTE provides functions of statistic analysis, by
which telecom operators can get more knowledge of c ustomer behavior and service
consumption. That is a very effective way to creat e re asonable marketing plans.
2.3.7 Flexible Price Configuration
Any price plan of a rating event in ZTE is decided by: event property (e.g., call-session time,
length, area, location, content, and byte), product (e.g., brand and bundle), customer profile,
and rating plan. The following Error! Reference source not found. shows the basic idea of
flexible price configuration.

Event properties
(time, duration, zone,
location, content, etc.)
Product data
Rating Plan Price of an Event
(Service, Brand, Package)
Customer Profile
(normal, VIP, Group, etc)
Figure 2 ZTE Fle xible Price Configuration
ZTE is able to process unidentified rating events by walking-through the steps as follows:
 Parse the unidentified event to a standard one with different properties (the property
can be dynamically defined even at runtime)
 Match the event properties with the related customer profile and product information
 Figure out the suitable price plan then prepare to rate it
All above steps are called pre-process of rating. In order to realize the flexibility and
expandability of rating engine, the pre-process rule, matching customer profile, matching
product information, event property, price plan, and tariff are all configurable. These
features enable Telecom operat ors to provide all services to pre-paid customers in short
time by system configuration.
2.3.8 Multiple Language Support
ZTE supports multiple languages, the benefits are listed below:
 Easily Used GUI
ZTE allows to switch to the preferred language of a user at any time.
 Enriched AoC
ZTE supports AoC with many channels, currently including voice, SMS, port al and etc. Also
AoC can be in any pre-defined languages according to customer profile.

2.3.9 Comprehensive Service-Bundle Support
By extracting properties of different networks and services to form products, ZTE can
bundle any of the services to implement discount crossing-network and crossing-product.
Such way ensures the carrier to vary its market strategy flexibly without constraint of
network differences.
The networks currently support ed in ZTE include PS TN, PHS, GSM/WCDMA,

CDMA/ CDMA 2000, and IP TV. Also the services cover voice, data, SMS, VAS and etc. As a
result, ZTE s upports convergent billing for session charging, bearer charging, and event
charging. Therefore, Telecom carrier is able to design then push flexible service-bundles to
market without any concerns about convergence.
2.3.10 Fully Web-Enabled Interface
The friendly web-enabled interfaces of ZTE mak e all operations easy and fluent. For
example, In order to ensure system running properly, a component, system management,
comes with ZTE to provide functionalities regarding privilege, backup, log, parameter, and
monitoring managements. All these functionalities are accessible through full functional GUI.
2.3.11 Carrier-grade Stability and Reliability
ZTE OCS is built on ZTE IN of ZXOS platform, the reliability of which has been proven in
hundreds of sites globally. In addition, all key modules of ZTE are deployed based on hot-
standby technology. So the services will automatic ally switch to another host in case of one
host failure. And the mechanism for memory data synchronization is adopted to make sure
the unint errupted services upon host switch.
2.4 ZTE Overall System Structure

ZTE OCS system mainly includes Service Control Unit (S CU) and Online Charging Unit
(OCU). General relations among SCU, OCU, NE and external systems are depicted by the
following Figure 3.

NMS SNMP
ZSmart OCS
MML
USSD/IVR MML/WebService/… UIP
UIP
External
Systems
OCU
OCU
MML
VC
VC CDR
OLC
OLC
Ro
Emergency
Interface SCU
SCU Ro
SS7
FTP
VAS HLR USSD SMSC MSC Network
Figure 3 General Internal and External Relation of ZTE OCS
SCU takes the SS7 signaling access and realtime service control functions; OLC receives
all realtime charging request from NE and returns the charging results to them. UIP is the
SOA-bas ed interface platform for easy external business application. In case of emergency,
Emergency Interface takes CDR file from NE and makes charging to avoid revenue loss.
VC is the recharging system for prepaid.
See Figure 4 for the system architecture.
SCU comprises of Service Control Proc essor (S CP), Service Management Processor
(SMP), Intelligent Peripheral (IP), and Voucher Center (V C).
OCU includes Database Server (DB), Online Charging Server, Application Server (APP ),
Unified Interface Plat form (UIP), Online Collection Server (OLC), and CDR server.

ZSmart OCS
OCU
DB Server Online Charging Server APP Server UIP Server CDR Server
TCP/IP
OLC Server
IP SCP SMP VC SIU SCU
DCC/SMPP/SMPP+/EMPP/Raduis
CAP/MAP/INAP
SS7 TCP/IP
Switch Soft switch

MSC / VLR GMSC
SMSC MMSC
CSCF WAP GW
PSTN/NGN 2G CS-Domain SGSN eGGSN
IMS-Domain VAS-Domain
3G PS-Domain
Figure 4 ZTE OCS System Architecture
1 SCP performs Servic e Control Function (SCF), and has the service logic processing
program (SLPS ) required for processing services. SIU provides SS7 interfaces to the
SSP and translat es between SS7 protocols and internal messages.
2 SMP is responsible for service management. It can load/unload the newly developed
services to S CP, manage ongoing service logic and modify service and net work data
on SCU.
3 IP provides resources required for supporting information communication between

users and the network. Such resources include: user specified special voice
announcement, synthetic language/speec h recognition devices, Dual Tone Multi -
Frequency (DTMF) number receiver, signal generator, switching matrix connecting
users to the resources, and Conferencing Bridge. IP can be connected directly to one
or more SSPs, or to the SS7 signaling net work.
4 VC applies the function of recharging for service users, i.e., in charge of providing
recharge service logic, creating and storing voucher card and voucher record database.
5 Online Charging S erver is the core charging part of the system. It performs the realtime
charging functions for the servic es. Based on the real-time message mechanism, OCS
receives the charging request and makes charging, according to the service data,
customer data and charging strategies, then returns the charging result to the network
elements.
6 Application S erver provides the interfac es for WEB related front-end applications of the
system, such as interfaces for system management, product management, and self-
care.
7 OLC S erver is the Online Collection part of the system, which processes online
message protoc ol adaptor and charging message distribution, meanwhile realizes the

load sharing and overload control of Online Charging Server by distributing messages
according to rules.
8 UIP is Unified Interface Platform, which implements the application interfaces using
MML, SMPP+, HTTP and socket private protocols with outside systems, such as VC,
SMC, CRM, etc.
9 CDR server stores and transmits the CDR files to external systems such as billing
system, BI system.
10 DB servers bear the database management for data such as service data, customer
data, and product dat a.
3 ZTE OCS Software Structure
3.1 SCU software structure

Inherited from IN technology, SCP performs service call control in the OCS. It mainly fulfills
the service control function (SCF), and processes the service logic programs (SLPs) of the
services implement ed on the OCS (hereaft er we refer them as IN services).
The SCF is implemented through S CM module software that provides the functions of
service logic processing of S CP.
The design philosophy of S CM module software is as follows:
1 SCM module software is designed in hierarchical and modular structure so that

updating on any module of any software layer and/or adding a new module will not
affect other modules.
2 SCM software should be error tolerant, and no minor software failures will result in
various serious restart of the system.
3 SCM soft ware should be designed with the protection function so that the error
occurred in a software module could be confined in that module only and would not
cause further errors in other software modules.
4 It should be able to monitor software running faults. Once major faults such as software
deadlock occur, it can restart automatically and report the faults instantly.
5 When S CM software version is being updated, calls under processing will not be
interrupted.
3.1.1 SCM software Module
The soft ware structure of SCM module is shown in Fig ure 7.

ALARM Module
SLPM Module
AP Module
SLEM Module
SLP Module
SCSM Module
Operation system module and communication module
Figure 5 SCP SCM Module Software Structure
The modules are designed as follows:
3.1.1.1 Operation System Module
This module creates a software operation plat form for the entire SCM software. It provides
unified system call primitives for other SCM modules to obtain the hardware-platform-
independent system service. It facilitates the migration of SCM modules on multi-hardware
platforms.
At the same time, the operation system module can also monitor other modules of SCM at
the operation system level.
The system call primitives provided by the operating system module include:
1 Primitives of dispatching the process and thread;
2 Primitives for calling the timer and time service;
3 Primitives for calling the memory management.
3.1.1.2 Communication module
With the message dispatching (communication) function for the entire SCM software, this
module provides unified communication service for all SCM modules. This functional
module implements the functional entity access function (FEAF) required in the SCF
software models. This module implements the following cap abilities of communication
service:
1 Provide reliable message transmission
2 Ensure the sequential transmission of messages
3 Permit the pair correlation of message request/response
4 Allow multiple messages to be mutually correlated;

3.1.1.3 SCSM (Service Control State Model) module
SCSM provides the finite state machine model of IN service calls for SCF to control a call
instance.
3.1.1.4 SLPM (Service Logic Management Module)
SLPM module is mainly engaged in the management of service logic data, and the specific
operations are required by the SMF functional entity in SMP. However S CM can accept the
management of SMF on the service logic data and inform SMP of the processing results at
the same time. Its main functions are as follows:
1 Loading of IN service data;
2 Activation of IN service data;
3 Deactivation of IN service data;
4 Unloading of IN service dat a;
5 Statistics of relevant information.
3.1.1.5 SLP (Service Logic Processing) module
SLP service logic execution module provides the IN service logic execution environment,
including:
1 Selection of call service logic;
2 Distribution of call instance resources;
3 Starting, maintaining and releasing of call instances;
4 Timer management of call instances;
5 Management of the call instances information according to SMF.
The call service logic defines the processing principles for an IN service call. Those
principles are embodied in the S IBs chain. The call servic e logic covers the following
aspects:
1 Conversion between the service logic and BCP and the data needed in the conversion;
2 The logic relationship between the SIBs constituting the service logic and the
interaction relationship between SIB and BCP;
3 Data input/output, including the SSD and CID of each SIB.
3.1.1.6 SLEM (Service Logic Execution Management) module
SLEM module implements in detail t he IN DFP functions. In the unit of individual S IBs,
SLEM module implements the FE functions required by IN services . Meanwhile it provides
the communication interface bet ween SCF and ot her FEs.

The communication interface realized by SLEM mainly includes the interfac e between
SSF/SRF and S CF, which is mainly specified by INAP, CAP and MAP .
SCP divides SIBs into two categories according to the functional actions realized in them.
1 The S IBs such as algorit hm and judgment that have no c ommunication requirements
with other functional entities are implemented in object-orient ed mode. The SIBs define
their static SSD data parameter, dynamic CID data and operation codes of
corresponding functional actions.
2 The SIBs that request to connect to other functional entities mainly realize operation
communication among INAP, CAP and MAP. These SIBs include INAP SIB, CAP SIB,
and MAP SIB.
3.1.1.7 Service Control Point Access Proxy (SCPAP) module
SCPAP enables S CP administrator and SMF t o access SCM, so as to manage SCM

software. As the interfac e bet ween S CM software and other functional modules, SCPAP on
one hand authenticates the operation and maintenanc e made by SCP administrator on the
relevant processes of SCF and informs SCP administrator of the processing result of
relevant processes of SCF. On the other hand, SCPAP receives from SMF functional
module the c ontrol commands on the S CF -related processes, forwards the commands as
required to the corresponding proc ess for processing, and informs SMF functional entities
of the processing result.
3.1.1.8 ALARM module
ALARM module monit ors the modules of S CM software. During the running of SCM
software, the module monitors the running status of the whole software system, and reports
the monitoring result to SMF or other processing proc esses.
3.1.2 Features of SCM software
1 SCM software system design features hierarchy and modularization, and the inter-
module communication complies with the internationally recognized standard interface.
The information flow is standardized. Maintenance and updating of any module will not
affect the normal communication of other soft ware modules.
2 SCM realizes the standard information flow between the IN distribution functional
entities, and provides the open and standard interface to int erconnect with other IN
functional entities.
3 Due to the SCM software implementation based on the standard C language, the
whole system software enjoys good transplantability.
4 The flexible and sufficient SIBs can satisfy various service demands. High level SIB
function can be provided as required. Th e technologies oriented at Knowledge B ase”
“Running Base” make it easy to add new S IBs.
5 Through providing the “Message SIB”, it is easy for the SCM software to connect with
the third-party interface/database, enhancing the expandability of the system.
6 SCM uses a highly reliable system or fault-tolerant system, and it can be based on the
open, standard and universal soft ware/hardware platforms and systems such as UNIX
or WINDOWS NT system platform.

7 SCM can separate the modules relat ed to service c ontrol/service data from database
management system. The concept of parallel processing is introduced into the service
control processing/service data module, so that the system enjoys stronger processing
capability and the capability of linear ex pansion.
8 Separation of the service cont rol module from the service data module enables linear
expansion of the t wo modules, and the system can be smoothly and steadily expanded
without interruption of the service.
9 With the universal and highly available server and commercial database technology,
SCM processor is free from single-point fault in general, enhancing system stability.
10 With flexible system configuration, it can meet various service demands;
11 It provides perfect load control and traffic statistics function, and signal ing tracing
function to help with operation management;
12 It complies with the requirements in the IN standard of ITU-T for implementing relevant
functional entities.
3.1.3 SCM software Functionality
SCM soft ware functions mainly include c all control and processing function, which are
introduced as follows.
3.1.3.1 Call control and processing function
SCM software realizes SCF service control function and serves as the control point where
OCS system centralizes service logic. For a call instance of an IN servic e, SCM has the
following control and processing functions:
1 Select service logic
The SLP module in SCM can select the proper service logic to process the call according to
the following information:
Service key
The dialed number
Called party number
Calling party number
Commercial group ID of the calling user
Caller type
Calling party sub-address
Call gap enc ount ered
IPSSP capability
IP availability

Location number
Miscellaneous call information
Original called user ID
Indicator of service profile
Termination type
Triggering type
Consistency of high level
Indicator of service interaction
Additional calling user number
Forward call indication
Bearer capability
BCSM event type
Redirection user ID
Redirection information
2 CAP version selection proc essing function
The relevant modules in SCM can support multiple CAP procedure versions. The SCSM
module in SCM interprets and proc esses the application context sent from SSP, and
specifies the CAP version in SCM based on requirements of the application context. If the
version is not supported by SCM, SCM may either send back a CAP version existing in
SCM to SSP, and SSP will start a new dialog with this application context or refuse this call.
3 Execution of service logic
The relevant call processing module of SMC selects routing for t he IN service call according
to the features defined in the service logic, and executes the service logic according to such
parameters as the caller address received from CAP operation, then connects the call to
the destination number or the announcement recorder.
4 Allocation of INAP, CAP and MAP messages
SCM can distribute operation messages that are carried on the SS7 signaling network -
based TCAP message to different service logics via the message distribution system for
processing. If one TCAP dialog contains several messages, the message distribution
system will guarantee all of them to be executed in sequence. If one TCAP message
contains several INAP, CAP and MAP operations, SCM will execute them in parallel or in
sequence as specified in INAP, CAP and MAP.
5 Queuing of INAP, CAP and MAP messages
SCM can distribute INAP, CAP and MAP operation messages that are carried on the SS7
signaling net work -based TCAP message to different service logics via the message
distribution system. If there are several TCAP messages for one service logic to process at

the same time, the S CM should queue the INAP, CAP and MAP operation messages
received and execute these INAP, CAP and MAP operation messages in sequence.
6 Cont rolling the play of recorded announcement
SCM can instruct IP or SSP (when SRF and SSP are set together) to play correct
announcement and/or collection information to the user as required in the execution of the
service logic.
SCM can instruct IP or SSP (when SRF and SSP are set together) to play announcement to
the user with the language of the service user or the language pre-defined by the user or
selected by the user via the announcement.
7 Processing of messages
SCM can send/ receive messages to/from other physical nodes containing IN functional
entities according to the selected service logic, so as to control the progress of calls:
i Receive the management message of SMF
ii Report statistics, alarm and charging messages to SMP
iii Receive the INAP, CAP and MAP messages requested and reported by SSP;
iv Send to SSP the INAP, CAP and MAP messages of instructions and request
report;
v Receive from IP the INAP, CAP and MAP messages of result report;
vi Send to IP the INAP, CAP and MAP messages of instructing IP to play recorded
announcement and/or collect information from users .
INAP, CAP and MAP are s ervice independent, but the selection of specific parameters in
INAP, CAP and MAP operations are servic e dependent.
8 Error control function
If the relevant service processing module of S CM finds error in the execution of service
logic, it will take the error specified in INAP, CAP and MAP and report to the corresponding
IN physical entity which will correspondingly process this call.
SCM will take necessary measures for the call according to the error type and s ervice logic
upon receiving the error returned from other physical entities. (For example, it will send
instruction to the corresponding physical entity again, so as to continue the call, or play
announcement to the user and have other physical entities release resources relate d with
this call, so as to end this call.)
3.1.3.2 Data and traffic management function
1 Service data management function
The specific operations to manage the service data are implemented by SMP (the
management scope varies with the management authority), but SCM can accept SMP‟s
management on the service data and it can inform SMP of the processing result.
i Activate/ deactivate IN services

SCM can activate or deactivate an IN service as required by SMP. If one servic e code is
deactivated, calls to this service code will be rejected, with one announcement tone or
recorded announcement played.
ii Activate/ deactivate IN numbers
SCM can activate or deactivate the servic e logic of a specified IN number as required by
SMP. If a specified IN number is deactivated, all calls to this number will be rejected, and an
announcement tone or an announcement will be played.
iii Restriction on IN servic e amount
SCM can limit and modify the quantity of calls to an IN s ervice as required by SMP. That is,
the maximum number of calls to this service in a cert ain period can be specified and if the
amount of calls to this service reac hes this maximum number, calls to this service will all be
rejected. Calls to one kind of service can be judged based on the access code.
iv Restriction on IN number amount
SCM can limit and modify the quantity of calls to a specific user number of a specific IN
service as required by SMP. That is, a maximum number can be specified for calls to this
user number within a certain period, and if such maximum is reached, all c alls to this user
number will be rejected.
2 Traffic management functions
One SCP receives calls from multiple SSPs, and large traffic may occur to SCP within a
certain period or from a service. Meanwhile SCP‟s processing capability is limited and it is
the core of the intelligent network. If SCP fails to run due to overload, the whole intelligent
network will be crashed.
Therefore, SCM provides the traffic management function, so as to:
i To make sure SCP has the capability of overload cont rol.
ii To make sure one separate service can not occupy all resources of SCP and
decrease the resources of this SCP available for other servic es.
iii To ensure the received calls can be processed correctly.
The traffic management functions provided by SCM include the followings:
i Cont rol the predicated large traffic in advance
SCM can control the large IN s ervice traffic that is predicat ed to occur to a service or within
a period. That is, the servic e logic proc essing process in S CM can s end “Activating Service
Filtering” operation of INAP, CAP and MAP to the SSF in SSP, so as to filter in SSP the
calls specified in the operation, instead of accessing every call to SCM for proc essing.
ii Check the overload status
SCM monitors the number of TCAP events processed at the same time.
SCM monitors the number of concurrent dialogs.
For some services, SCF monitors the number of calls to a destination or number or a
service access code;

Accept the monitoring by the network or service management center over the traffic.
3 Message encoding/decoding functions
SCM can encode/decode TCAP messages, so as to receive/send TCAP message from/to

other physical entities via SS7 signaling network, that is, it can decode the received TCAP
message for the service logic to run in its implementation environment. When SCM is ready
to send messages to other physical entities, all the parameters and operations to be sent
must be loaded into t he TCAP message, that is, to encode the TCAP message, so as to be
transmitted in the SS7 signaling network.
The TCAP message processing functions in SCM are implement ed by SCSM module.
4 Statistical function
SCF can make statistics as required by SMP and S CF itself, and meas ure and record the
items for statistics, and report the statistic results to SMP as required by SMP.
SCM can measure the items one by one or several items together, and it can measure
them in sequence or at the same time.
i Counter proc essing.
SCM can res erve, add and reset the counter functions for statistics.
ii Statistic items
The following statistic items are availabl e in SCM
A) Statistic items for each service
SCM provides the following counters and can extract values from the counters at any time:
Incoming TCAP;
Outgoing TCAP;
Incoming TCAP abandoned for any reason;
Outgoing TCAP abandoned for any reason;
Incoming TCAP abandoned for software reason;
Outgoing TCAP abandoned for software reason;
TCAP unreasonable message;
Times of international toll call, national toll call and local call.
Times of seizure for calls with a real called party, completed calls, answers, subscriber
release early, releas e while ringing, ringing time out, trunk busy, and called busy.
Total call attempts to each service.
Call attempts of various services to the local SCM.
Call attempts of different originating areas to the service.

Meanwhile, SCM can make statistics on the specific features and requirements of different
services according to the requirements of the service management department.
B) Total IN operations of each service
SCM can provide the following instantaneous values, that is, the counter value repres ents
the quantity of calls or event processing being processed at any moment, and SCM can
extract the value from the counter at any time:
Number of IN calls;
Quantity of TCAP event processing
C) Statistic items related to specific IN calls
When it is necessary to make statistics of some information of one call, SCM can send the
“Call information request” (CallInfoRequest) operation to SSP as required by the service
logic processing, so as to request SSP to report to S CP the statistic information required by
CallInfoRequest through the “Call information report” (CallInfoReport) operation after the
call is ended. The specific statistic information required in CallInfoRequest operation
includes:
Call attempt duration
End time of a call
Connection time of the call (the time starting from receiving the ans wer signal to the release
of the call)
Called address (the called address not translat ed by SCP)
Release cause
5 SCP-SSP relation check
During the service processing, SCM can check whether there is any control relationship
between t he service proc essing process of SCM and SSF/ CCF process of SSP when a call
is going on. During a call processing, if SCM has not received any message from the
relevant proc ess of SSP for a long time, it will send “Activating Test” operation to the SSF
functional module in SSP. If SCM receives the result returned by such SSF functional
module wit hin the specified time, it means the relationship exists between them. Otherwise,
the relationship will be considered by SCM as being lost for some reason, and SCM will
take proper actions to process this call.
SCM has a timer to specify the longest time duration when there is no message transferred
between the service processing process and the relevant module of SSP duri ng a call
process, and the value of the timer is specified during system initialization.
3.1.4 SMP software structure
3.1.4.1 Software structure of SMP
SMP mainly consists of the following modules, as shown in Figure 8.

Service configuration
?function
? ? ? ? ?
SMAP Access Service provisioning

SMAP ? ? ? ?
function ?funciton
? ? ? ? ?
Service operation control

? ? ? ? ? ?
function
Communication
? ? ? ?
module
Service monitoring
? function
? ? ? ? ? ? ?
Figure 6 SMP Module Structure
3.1.4.2 Main functions of SMP
SMP and SMAP jointly provide the following five functions:
1 Service configuration function
2 Service providing function
3 Service running control function
4 Billing Management Function
5 Service monitoring function
The SMAP (Service Management Access Point) enables the network operators and
operators of the service user to access SMP.
1 Service configuration function
SMP service configuration function includes service text distribution, service basic data
distribution, and introduction of service user basic data.
 Network equipment configuration
The operator can access SMP from SMAP, and manage S CP equipment, monitor
equipment running status, and forc edly establish or disconnect connections bet ween the
equipment.
 Receiving the service package
Service packages included are as the followings:
 Service implementation logic: used in SCP to process calls.
 Service management logic or program: used in SMP and SCP to manage services.

 Service data template: including the servic e data on S CP, SDP and SMP,
structure information of the service user data and the data structure related to the
service management.
 Specialized resource information: recorded announcement ID used in SSP, SCP

and IP, recorded announcement texts, etc.
 Service interface program: used in SMP and SMAP to input the servic e data and
service user dat a.
 Service text configuration
 Specify the SCP to be loaded wit h the new service or new service version, and
load to this SCP the new service execution logic, the service management logic
(SCP part) together with the service key and the version No..
 Duplicat e the service management logic (SMP part) to the corresponding position
in SMP.
 Configure the service interface program to SMP.
 Configuration of the service data template
 Specify the network unit to be loaded with the service dat a template, i.e., SCP and
SDP, and load the service data template of the new service or new service version
to such unit, for the management of the corresponding network units.
 Load the corresponding management data template to the SMP databas e.
 Special resource data introduction and distribution
Specify the VRM t o be loaded with the resources data of the new service or new service
version, and load the new resources data, service key and version number to the V RM. On
SMAP, the voices edited can be loaded to VRM, while existing voice res ources on VRM can
be added, deleted or modified as well. After the modification, instruct the VRM to reload the
resources data.
2 Service providing function
This function is mainly used to introduce and distribute the service user dat a.
SMP can collect the data specified by the service user and manage the data in the user
database. It also converts the service and service data into the data as required by the
network, specifies the network units related to the servic e user data and manages the
corresponding network units.
Meanwhile, SMP can input the service user data in batch from the disk.
The service user data management interface can be downloaded from SMP to SMAP for
local running. Therefore, it is unnecessary to customize the user data management
interface every time when a new service is generat ed. The interface can be generated
automatically simply by modifying and loading some configuration information, which is
really convenient.
3 Service running control function

The service running control function mainly includes: service maintenance, service data
updating, overload management, service activation/deactivation, uninstalling the service,
access management, data allocation, etc.
 Service maintenanc e
SMP can save the service dat a and service user data on the net work unit, and can also
implement check function.
SMP can check the data and program in SCP manually or at the set time.
SMP can judge whet her the data discrepancy, if any, found during t he check is normal or
not. SMP can process faults, if any, in the preset way (such as sending alarm information,
modifying the data by itself, and ordering SCP to modify the data).
SMP can check either a specific datum or all the data of a specific service.
SMP can check the data either regularly or in case of any fault.
Checking of the service logic or the data by SMP will not influence the call proc essing in the
network.
 Overload management
The operator can order S CP to start call filtering from SMP.
SMP can manage the control type, call gap standard, call gap content, gap indicator
(duration and interval), and the processing mode of the call gap in respective S CPs.
In case of overload, SCP will aut omatically start the call gap of the corresponding level
according to the gap starting condition and report to SMP, which can save all the gap
information sent by SCP.
 Activation and deactivation of the services.
The service can only be used normally after it is loaded successfully and activat ed. The
service key is used to identify a servic e.
SMP can activate or deactivate any successfully loaded service. The operation is service-
key-specific and version-specific, that is, only one version of a service is active at a time.
 Uninstalling services
SMP can not uninstall the service being activated in the network. To unload a service
completely, the operator should first deactivat e the service of a certain version, and then
uninstall it from the net work.
At the time of uninstall, it is necessary to specify from which network equipment to uninstall.
It is allowed to uninstall the service only from some of the equipment.
 Access management
SMP operators include service user operators and service operators. Service operators are
further divided into service providers and network providers.
 SMF network provider

The SMP net work provider is responsible for managing SMP plat form access function,
managing the operators related to access, managing the SMP logon ID, managing logon ID
authority, and managing the net work equipment, an d also responsible for starting a new
service, updating the current service, starting database backup, and starting the check on
the data on SCP/SDP.
 Service provider
The service provider is res ponsible for the detailed management of the servic es, for
example, managing the service-related data, service user data, starting t he service
measurement, querying the measurement results and managing the service alarms.
 Service user operator
The operator can access SMP. In the management service the service us er i s allowed to
manage the data by himself.
The access approaches: SMAP can access SMP via t he LA N, packet network, telephone
network and DDN.
 SMP supports a variety of SMAP user interfaces
SMP provides different GUIs for operators of different types; meanwhile, it provides different
GUIs for the operators of different levels in the same service. SMP can work with SMAP to
load the user interface required by SMAP to the corresponding terminal.
 Create logon ID
The logon ID created for an operator by SMP includes mainly the following items:
Logon ID, logon ID type, password used for logging on ID, operator type, and office party of
maintenance.
To ensure maximum flexibility and usability, it is recommended to make the logon ID as

simple as possible when creating it, and as flexible as possible when creating the operator
type. The authority of each operator type can be specified. All function authorities available
in the system can be divided at will.
 Delet e the logon ID
Only the operator wit h due authority can delete the logon ID, wit h the operations rec orded in
detail in t he operator logs. Make sure to retain the corresponding deletion information when
deleting such ID. Only authenticated operators can delete the logon ID.
4 Service monitoring
 Measurement starting
SMP can monitor the service use, the service performance and the network performance as
well. It can implement the following measurement functions:
 Measurement of the service use conditions
Calls count of each service.
Calls count of each service to different SCPs.

Calls count at different origins for different services.
Distribution of various service call traffic among different SSPs.
The numbers of international toll calls, national toll calls and local calls, and their distribution
among different SSPs and SCPs.
 Measurement of the service performance
The followings for the call which truly has the called: Call holding times, connection times,
answer times, the times of subscriber release early, times of ringing time out, trunk busy
times, and called busy times.
The average call waiting time, the average calls duration and the call completion rates.
 Measurement of the net work performance
A) SCF traffic measurement
The SS7 signal link conditions between S CF and the preceding signal points (the number of
messages received, the number of messages sent to SSP, the number of error messages,
the number of discarded messages, etc.)
The CAP conditions between SCF and respective SRFs (the number of INAP, CAP and
MAP operations sent, the number of INAP, CAP and MAP o perations received, the number
of errors found by SCF, the number of errors returned by SRF)
The INAP, CAP and MAP conditions between SCF and respective SRFs (the number of
INAP, CAP and MAP operations sent, the number of INAP, CAP and MAP operations
received, the number of errors found by SCF, the number of errors returned by SRF)
The number of messages between S CF and SMF (the number of instructions received from
SMF, the number of messages sent to SMF, the number of error messages, the number of
discarded messages, etc.)
Call gap information (call gap type, call gap status, call gap standard, gap duration data and
interval, gap processing)
B) SSF traffic measurement
Number of call failures caused by caller abortion, SCF failure or SSF failure.
Number of queries to SCF.
A verage waiting duration for each call.
Calls gapped due to call gaps.
The number of gapped calls for every call cap type
Call gap information (call gap type, call gap status, call gap standard, gap duration data and
interval, and gap processing)
C) SRF traffic meas urement
The number of times that timeout results in user information collection error.
D) SMAF traffic measurement

Times of access to SMF operator from respective SMAFs.
Access times of each service.
Access times of each service user.
Times of failed access.
Access times to the network management functions.
 Collecting measurement dat a
The items for measurement are specified by SCE when creating the services. SMP orders
the network unit to collect corresponding service data or service user data, and send the
collected data to SMP.
SMP can organize multiple measurement items into a measurement set.
SMP can adjust the measurement set and the items in it.
SMP can adjust the frequency to collect measurement information as required. Multi ple
measurement sets can be set for a service (service user or call), and there can be several
measurement items in a measurement set. All the measurement items in a measurement
set have the same measurement frequency, but different measurement sets can ha ve
different measurement frequencies.
SMP can require the network unit to start measurement, end measurement, or make
measurement in a period of time.
 Analyzing the measurement data and generating a measurement report
SMP can order the network unit to send the measurement/statistical data to SMP at the
specified time or regularly, and it should be able to order the network unit to collect
information and send the meas urement/statistical data to SMP according to SMP order.
The interval at which the network unit sends the measurement result to SMP can be set in
SMP, meanwhile, there are parameters to specify the time at which the data are sent to
SMP if the network unit fails to send the data (or data preparation fails).
SMP can save the measurement informatio n. SMP can save to an appropriate position the
information sent by the net work unit to make another measurement/statistic
SMP provides reports in table and graphical forms.
SMP can, as a task, generate regularly and aut omatically the statistical/measurement
reports.
 Error monitoring data information
The faults that can be monitored during servic e running are specified by SCE when creating
the servic e.
SMP can instruct the network unit to report some alarms not specified by service, and can
save all the information such as error codes, date, time and the network unit.
SMP can monitor faults during the running and can save the fault report information
collected from SCP/SDP.

SMP collects the alarm information and reports it to the alarm box.
SMP can translate fault codes into corresponding fault information, and display the fault
event report on SMAP as prearranged according to the fault level.
In case of major faults, SMP displays the alarm information on the alarm box.
The operator can query history alarm information on the int erface via SMAP. The query can
be based on alarm time, service key, alarm level and alarm type.
5 Unique task dispatching function
SMP provides unique t ask dispatching function, in which powerful dispatching mechanism
can be set. The tasks can be set to be executed at a single time or periodically in a year, a
month, a week or a day. Within each cycle, the task may eit her be executed by a certain
interval, or at multiple specified time points. Start/end time can be set for each cycle.
The specific tasks to be dispatched may be diversified, such as TCAP tracing, database
check, a database operation and a certain type of traffic statistics.
3.2 OCU Software Structure

ZTE OCU adopts the centralized multi-tier archit ecture. All the functional packages share a
centralized database, which ensures the data consistence without redundancy. Each
package exposes its internal functionalities via standard service-based interfaces.
Therefore, the ZTE is loosely-coupled and service orient ed. In order to approach different
goals, ZTE technical arc hitecture can be divided into two parts: front -end and back-end.
 The front-end architecture
The front -end architecture is adopted in modules dealing with business management, such
as Customer Care, and Order Management. Most of this kind of modules own WEB or Web
Service based interfaces, so JAVA is adopted as the development language.
 The back-end architecture
The back-end architecture focuses on performance for processing a large amount of dat a.
In ZTE, this architecture is adopted in charging functional packages. The back-end
architecture has two typical models: batch-process and online process in terms of different
business logic.
The following sections introduce two architectures individually.
3.2.1 Front-end Architecture
This architecture depicted in Figure 11 is adopted in Product Management, Customer

Service, Order Management and etc. The key benefits are listed below:
 Rapid service development and test
 Support customization to address real demands
 Flexible system configuration

 Simple deployment and maintenanc e
 Unlimited expendability
 Full compatibility with major hardware/software platforms
Browser SMSC VC SCP ThirdParty System
Access Layer
HTTP SMPP VC MML SOAP Other
Gateway Gateway Gateway Gateway Gateway Gateway
Business Object
Business Logic Layer
Infrastructure
Product Components Project Components
Biz Engine
Communication Layer
MML SMPP SOAP Other
Adapter Adapter Adapter Adapter
Socket JDBC JMS CDR
Adapter Adapter Adapter Adapter
Network Element ThirdParty System
Figure 7 ZTE OCU Front-end Architecture
As shown in Figure 9, this architecture consists of 5 parts as below:
 Access layer
Parse the interaction protoc ol and response to the service request from external systems
 Business logic layer
Include common and customized business process packages
 Communication layer
Encapsulate interaction protocol and send service requests to external systems
 Business Object
Store the business data, and in charge of the data delivery among different layers
 Infrastructure
The fundamental platform of ZTE

3.2.2 Back-end Architecture
This architecture is applied in charging functional packages for the purposes of high
reliability, performance, and flexibility.
3.2.2.1 High Reliability
ZXOS of ZTE IN has been proven in hundreds of projects. The framework of ZXOS is
depicted in Figure 13.
Monitor
Alarm
SessionMgr
PCdrGen
DBAgent
OCPro
OCDis
Business Lay Device Info

gather
Business Info
gather
Support Layer ZXOS
Operating System
Figure 8 ZXOS Framework
As depicted in
10, the major functionalities of ZXOS are explained as follows:
 Encapsulate the differentiations of different operation systems, offer the unified

development interfaces
 Encapsulate the communication details with a unified interaction met hod
 Offer common services for management
 Provide functions of timer, monitor, service starting/stopping
 Utilize monitoring function, so it will restart service instances in the exceptional

situation
All key modules of ZTE are deployed based on hot-standby technology. Once a host is
failed, the services will automatically switch to another host. Also the mechanism for the
data synchronization is adopted; so the services will not be interrupted. The following Error!
Reference source not found.11 demonstrates the main concepts of hot-backup based on
Oracle TimesTen technology.

TimesTen TimesTen
Master Insert／Update／Delete Slave
Insert／Update／Delete Hot Standby
Online Online
Charging Charging
Process Process
OCU Server OCU Server

Primary Secondby
Figure 9 Demonstration of hot-backup based deployment
3.2.2.2 High Performance
In order to pursue the highest performance, ZTE adopts two memory-based mechanisms:
shared memory and memory database. Some relatively static information (e. g., customer
profile, and rating rule) are loaded into shared memory from harddisk RDBMS by specific
applications. Other frequently changed information (e.g., balance, accumulation, session)
are loaded into memory databas e on primary host from the disk -based RDBMS; and these
frequently changed information is copied to standby host memory DB through the
replication mechanism real-timely.
The following figure 12 shows the utilization of memory based mechanisms.
TimesTen
InMemory datebase
Accumulation
Balance
Online Charging history
Process
Balance
Session
Share Memory
Customer Profiles Billing Rules
Figure 10 Utilization of Memory-based Mechanisms
In order to do the batch-process tasks more efficiently, ZTE adopts the concurrent -process
technology. The following Error! Reference source not found.3 demonstrates how to
utilize multiple channel technology to realize conc urrent process.

Rating flow
gather Convert DupDetect Preprocess Pricing Store

CDR
CDR
files
CDR
files gather Convert DupDetect Preprocess Pricing Store
CDR
files
CDR
files
CDR
files Database
CDR
files gather Convert DupDetect Preprocess Pricing Store
CDR
files
files
gather Convert DupDetect Preprocess Pricing Store
Figure 11 Mechanism of Multiple-channel
3.2.2.3 System Flexibility
ZTE is able to dynamically load suitable BizLogic Objects at runtime to process business
requests according to configuration file. The main idea is depicted in the following Figure 14.
COMMON INTERFACE
Open Library Application
Cet
Load symbols
Address
Object
Bizlogic
Factory
Object
Create Create
Create Instance
Instance
Figure 12 Process of Dynamical Loading BizLogic Object
3.2.3 OCU Functional Packages
ZTE OCU functional packages are listed in the following figure 15; they are Customer
Management, Product Management, Inventory Management, Account Balance
Management and Charging.

Customer Management Product Management Account Balance Management
Balance Rule Management

Customer Profile Configuration Tool
Management
Product Specification Balance Change Management
Subscription Price Rule
Management
Balance Consumption
Reference Repository
Charging
Inventory Management
One-off Charging Rating Engine
Number Stock Management
Recurring Charging Online Charging

Resource Assign Processing
Usage Charging
Figure 13 ZTE OCU Functional Package
The functionality of the packages is described in following chapters.
3.2.3.1 Customer Management
 Customer Profile Management: this function is to collect, search and update the
customer information such as customer Identification information, payment mode,
address, contact information and so on.
 Subscription Management: Contract Management manages contrac t clauses and

instances of the Offer/Product/Price Plan the customer purchases from carrier. Its
function includes creating, updating, and canceling the instance, and changing
lifecycle.
3.2.3.2 Product Management
 Configuration Tool
Product Management module provides WEB-based configuration tool, and all the
configuration information related with Product can be configured through the WEB -based
GUI. The WEB-bas ed GUI of product management also provides the function to
export/import price data to simplify the price configuration and modification.
 Product Specification
Product can be the service provided by network, physical article, or Price Plan launched to
market by carrier. Product Specification also defines the product status related with net work,

for example, net work services included, parameters of the net work services, and the
properties of the product itself, such as color and size.
 Price Rule
Price Rule defines such things as Price Plan, the relation bet ween Price Plan and Product,
effective date of the P rice Plan, version of the Price Plan, and rating rules of the Price Plan.
Rating Rule includes the rule for usage fee, recurring fee, one -off fee and discount rule.
 Referenc e Repository
Referenc e Repository provides basic data support for Product and Price Pla n. For example,
Int‟l long distance Area Code sheet and customer property category sheet.
3.2.3.3 Inventory Management
Inventory Management manages logic resource (such as number and IP address) and part
of physical resourc e (such as SIM card). And the management function dynamically and
hierarchically realizes order creation, resource creation, resource dispatch, resource
reservation, resource occupation, resource release, resource reclaim, resourc e construction
and data processing during operation.
 Stock Management
Stock Management manages the resource quantity throughout the operation. The reasons
resulting in quantity change can be stock-in, stock-out, resource delete, resource dispatch,
return the resource to t he vendor, customer exchange the resourc e and reclaim the
resource.
 Resource Assign
Resource Assign is to manage the operation on resource, including resource reservation

and release, resource occupation, resource information modification, resource deletion,
resource maintenance, customer return the resource and customer exchange the resource.
3.2.3.4 Account Balance Management
ZTE 's Account Balance is a customer's resource that can be used to pay for his/her
consumption. It can be either the monetary balance or t he non -monetary service usage
(such as the amount of free SMSs). It can be recharged or purchased by the customer or
offered as presents/benefits by the carrier.
 Balance Rule Management: it can define the balance type and the balance
consumption rules, such as:
 Dedic ated consumption, that is, the balance can only be used to pay for specified
services;
 Balance share among different subscribers;
 Cons umption limit on t he cycle, such as daily ceiling (maximum) consumption and
monthly ceiling (maximum) consumption.

 Balance Change Management: The balance and balance valid period can be changed
when cert ain activities happen, such as recharge and balance expiration. Balance
Change Management includes the functionalities of generating, cancelling or
invalidating account balance. It also provides interfaces to change the account
balance, such as balanc e debit and balanc e trans ferring.
 Balance Consumption: it includes the functionalities in the Charging package such as

balance reservation, balanc e release and balance deduction.
3.2.3.5 Charging
Charging calculates usage fee, recurring fee and one-off fee. There are two modes of
charging: batched charging processing (based on file or periodically) and online charging
processing. And the same Rating Engine is used in both modes.
 One-Off Charging
One-Off Charging makes charge for customer contact event, for ex ample, purchasing an
offer, changing service, and query. One -Off Charging c an be the quotation before the event
happens, e.g. before the customer purchases the offer, or charging after the event.
 Recurring Charging
Recurring Charging make charge for rental fee such as monthly rental fee, daily rental fee
or other periodic rental fee. This package supports two modes of fee collection: pre -collect
the fee before the billing cycle starts, and collect the fee after the end of the bi lling cycle.
 Usage Charging
Usage Charging makes charge for customer usage record, the usage record can be CDR
or online charging request.
 Rating Engine
Rating Engine adopts event-driven mode. Under such mode, all charging requests are
transformed to standardized Ratable E vents, so the Rating Engine can make charge for
events of any type. Rating Engine functionality includes transforming the event to standard
event and matching the standard event with customer information and price plan, and then
calculating the charge for the event.
Online Processing: Online Processing processes online charging requests in real time.
The processing functions falls into t hree modes: price check, reservation/deduction, direct
deduction/refund.
Price check mode is used to tell the price of a one-off event, or query if the balance is
enough for some service. Reservation/deduction mode is used to process session-based
charging requests, for example, in online charging mode, upon the user originates a call,
the system first make res ervation and after the call ends, the final us age fee is calculated
and deducted. Direct deduction/refund mode is used to process event -based charging, for
example, upon the user sends a SM, the system first deducts the fee, and if the SM is failed,
the system refund the fee to the account.

4 ZTE Concept Model

The entities in ZTE framework are organized in several domains. The domains relating with
Offering and Billing requirement are schematized by Figure 16.
Product Domain Event Domain
•Product Offer •One Off Event

•Product •Recurring Event
•Service •Usage Event
•Apply Condition •Event
•… •…
Customer Domain Pricing Domain Balance Domain
•Customer •Price Plan •Balance Type

•Account •Rate Plan •Balance
•Subscriber •Accumulator •Balance Share Rule
•Offer Instance •Discount •Accumulation
•…. •… •…
Figure 14 ZTE Concept Mode
The detailed explanation of concept domain introductions is presented in the following

chapters.
4.1 Product Domain

Product Offer Catalog Product Offer Group
Product Offer Group Relation
Product Offer
Region Group Product Offer Relation
Price Plan
Channel Product Relation

Apply condition
Customer Group Product Attribute

Product
Time Period
Service Type
Service
Main Product
Action Service Non Network Service Network Service Additional Product

Figure 15 Domain Products: Actors Relation
The Product domain includes product offer catalog ue, its member specification definition
Key entities description:
Table 1 Product Domain Entities
Entity Name Description

Product Offer Product Offer is a purchasable product or service bundle with
specific pricing rule.
Life cycle attributes are defined for product offer.
Product Product can be used to define either Commercial Product or
Activation Product (technical one) depending on the
corresponding attribute.
So it can be is a purchasable unit; it can be network service like
GPRS, tangible good like handset, abstract service like „favourite
number‟.
Life cycle attributes are defined for products.
The many-many relationship between Product Offer and Product
is defined in Product Offer Detail entity in implementation stage.
Service This is a non-commercial product (technical one) and is
implemented using Product entity feature. A network service
needs activation like Caller Identity, or non network service like
„product offer upgrade‟.
Service Type A Service Type categorizes services, for example GSM Service
Type.
Apply Condition A constraint rule set applied to Product Offer/Product/Service
Action.
Product Offer A Product Offer Group is a set of product offer with some
Group common characters.

4.2 Event Domain

Service Price Plan
Event
Non Network Service Network Service Usage Event One Off Event Recurring Event
Action Action Service
Product
Product Action Service
Product Offer Action Service Product Offer
Figure 16 Domain Event: Actors Relation
The rating and billing engine of the ZTE system is designed as an E vent-Driven arc hitecture.
The E vent domain describes the event type that rating engine can proc ess their generation
rule, filtering rule, sorting rule, storage rule etc.
Table 2 Event Domain Entities

An abstract entity expresses all pricing request, system actions etc.
It is categorized to Usage Event, Recurring Event, and One-Off Event.
Event
A decision tree is used to identify and convert the input event to a
chargeable event.
A One Off Event is generated by customer interaction, for example:
One Off Event subscribe a product offer, cancel an option, call list printing, etc.
Price or bonus or penalty can be calculated.
Recurring Recurring Event is generated periodically by the product/product offer
Event purchased by the customer.
Usage Event Usage Event is generated from the network.

4.3 Price Domain

Product Service Event
Price
Zone Mapping
Price Plan Parameter Price Plan Rate Plan Bonus
Rate Plan Version

Subscriber Default Price Plan Python Script
Benefit Selector and Calculator
Trigger
System Default Price Plan
Time Span
Individual Price Plan Accumulator Trigger Accumulator
Discount Price Plan Accumulator Range

Trigger Action Account Balance Trigger Tax/Add Fee
Offer Price Plan

Calendar
Billing Discount
Figure 17 Domain Pricing: Actors Relation
The Pricing domain describes the price plan and its member‟s attribute and relationship.
Table 3 Price Domain Entities

Price Plan is a set of price rules applied to a product offer.
Base on the different effect scope and different effect mode (override or
Price Plan supplemental), it is classified to different type, for example System Default
Price Plan taking effect system wide, and others taking effect only when
customer subscribed it.
Rate Plan is a set of calculation rule for a specific event type in a price
plan.
Rate Plan
Price, Bonus, Accumulation, Benefit, Tax/Add Fee, Discount rules are
defined in Rate Plan.
A set of rules define the selection rule and calculation rule. Flexibility is
Selector and
gained from reference table, zone table, calendar, and time-span and
Calculator
python script.
Rules defined based on account balance threshold or accumulation
Trigger threshold. Actions can be defined when threshold matched, for example:
send a notice SMS to customer, or generate another event.

4.4 Customer Domain

Apply condition
Work Flow Work Flow Template
Action Service Order

Agreement
Account
Offer Instance Customer Balance
Product Offer
Subscriber
Main Product
Price Plan Instance Close User Group

Price Plan
Subscriber Relation
Favorite Number
Product Instance Additional Product
Price Plan Parameter Price Plan Parameter Value
Product Attribute Value Product Attribute

Resource
Figure 18 Domain Customer: Actors Relation
The Customer domain describes the customer information of the operator and their
subscription information.
Table 4 Customer Domain Entities

A Customer is a person or an organization who own the service
Customer and responsible for paying the bill. It also can be a prospect
who will buy the service at future.
An Order is generated by customer interaction, for example,
subscribe a product offer.
One or more Product Offer(s) can be selected and stored into
Order the ZTE shopping cart. After Confirmation the shopping cart
becomes a Customer Order which is then decomposed in
Services Orders.
Workflow is used to control the processing flow.
A Subscriber is a main product instance; it is also the „user‟ of
Subscriber
the product.
An Account is the customer‟s payment entity. It can be a bank
Account
account, or just an abstract entity for cash payment.
Product Instance Products owned by the subscriber.
This is the Contract signed between the Customer and the
Agreement
service provider, it defines the commitments for both party and

penalty rules.
4.5 Balance Domain

Balance Type Balance Constraint
<<instanciate>>
Account Balance Balance Constraint Inst
Account Book Balance Share Rule Subscriber
Accumulation Type Accumulation Cycle Type
Accumulation
Figure 19 Domain Balance: Actors Relation
The Balanc e domain describes the generation and usage rule of the customer balance
accumulator generation and us age rule.
Table 5 Balance Domain Entities

A balance can be currency, or non currency like free usage.
An account may own more than one balance.
Balance
Balance have effective and expire date, and have usage
constraints.
Balance Constraint is a rule set defines the balance limitation
Balance Constraint usage duration a period, special usage for curtain charge type
etc.
A balance can be shared among some subscribers for same
kinds of usage type, for example, a CUG group shares a
Balance Share Rule
balance for their CUG calls. The sharing rule is defined in
Balance Share Rule.
Accumulation is a kind of resource generates by the offering
Accumulation
and billing process and can be referenced by the pricing rule.

5 ZTE Product & Offer

The static view of the product domain:
Product Offer Group Relation
Product Offer Relation in Group Product Offer Group
Product Offer Constraint
Product Offer Group Member
Price Plan
Product Offer Attribute
Product Offer Product Offer Relation
Product Offer Service Offer
Product Offer Detail
Attribute List
Product Relation Product Product Attribute
Attribute Value
Product Group Member

Product Service Offer
Service Offer Eligibility Channel
Product Relation in Group Product Group

Page Attribute control
Service Offer Relation
Product Group Relation
Figure 20 Static View of Product Domain
 Products are elementary units and cannot be directly ordered by customers. Product
information is defined by the [Product] entity and c haracterized by these following
attributes: product name, code, product category, state, effective time, expiry time,
product type and product sub-class. Product attributes can be dynamically expanded
and are recorded in the form of a longitudinal table.
 Product category is used to differentiate Service products from Physical products.
 Product type is used to define whether the product can be purchased alone, or
whet her the product is a Main product or a Supplementary product.
 The product attributes descriptions are defined in the Attribut e List entity, for instance,
data type, input mode, null or not, default value, minimum value, maximum value, etc.
If a product attribute has multiple possible values, then the specific values shall be
defined in the Attribute Value entity. The Attribute Value entity can also define the
sequence of value displ ay.
 The Product Service Offer entity defines the management actions associated with each
product (for example : GSM Initial subscription)

 The Product Relation entity defines the relations among products, including the
prerequisite constraints and the exclusion constraints.
 The Product Group entity and the Product Relation in Group entity define the relations
between two products, (e.g. the mutual exclusion of Products A, B and C).
 The Product Group entity and the Product Group Relation entity define the relations
between groups (For example, Group A contains A1, A2 and A3, Group B contains B1,
B2 and B3, then the relation between products An and B n can be established onc e the
mutual exclusion relation of Group A and Group B is defined).
 Customers can only order Product Offers. The product offer information is defined in
the Product Offer entity and the content includes name, brand, code, state, product
offer type, effective time period, effective policy, validity period, contract extension
policy, and extended period.
 The effective time period is the lifecycle of the product offer.
 The validity period is the validity period of the product offer after the product offer
is ordered by the customer.
 The extended period is the period of extension time defined if auto extension
applies after the customer‟s validity period expires.
 A Product Offer is composed of Product, Price Plan and Product Offer. The
composition is defined in the P roduct Offer Detail entity. The Product Offer Detail entity
defines the elements of the product offer, the minimum/maximum value of
ordered quantity of the elements, the relations between elements and whether
the default value is used.
 If the minimum value of the ordered quantity is 0, then this element is optional.
 The relations between elements can be mutual exclusion, dependency, etc.
 Because a product offer can contain ot her product offers, product offers have a
hierarchical relationship.
 The Product Offer Service Offer entity defines the actions correlated to the product
offer. It also defines in which state of the product instance a Service Offer can be
applied for.
 The Service Offer and Eligibility Channel entities define which channels or which sites
support which Service Offer operations.
 The Service Offer Relation entity defines the relations between services. It supports
correlated processing relations including pending, mutual exclusion and coexistence
when a user applies for multiple servic es at the same time.
 The Page Attribute Control entity defines the presentation mode of t he page display
control for each service, including whether it is visible, whether it is read-only …

 The Product Offer Attribute entity defines the attributes at product offer level or fixed
product attributes, for example, the ADSL product offer whose bandwidt h is fixed as
2M.
 The Product Offer Relation entity defines the relations between product offers.
 The Product Offer Group entity and the P roduct Offer Relation in Group entity define
the relations bet ween two product offers.
The concept model mapping with physical model follows this table:
Table 6 Concept Model Mapping with Physical Model
Concept Model Physical Model

Service Product
Non Network Service Product
Network Service Product
Product Product
Action Service Service Offer
Relation between Action Service and
Product Service Offer
Service
Main Product Product
Additional Product Product
Product Attribute Product Attribute
Product Relation Product Relation
Product Offer Product Offer
Product Offer Relation Product Offer Relation
Relation between Product Offer and
Product Offer Detail
Product
Apply Condition Product Offer Constraint Rules
5.1 „Product Relation‟ Configuration

 Define the relation bet ween the main product and the supplementary (or Additional)
product. For example, the GSM mobile (main p roduct) is relat ed to the Call ID and
THREE -WAY CALLING services.
 Configure the relation between the main product and the supplementary product,
(default or option)
 Define the exclusive relation bet ween the products in the same level. (For example:
between two main products or two supplementary products). When the customer
orders A, he cannot order B.

 Define the dependency relation between the products in the same level. (For example:
between t wo main products or two supplementary products). The customer c an order A
only if he has already ordered B (prerequisite rule feat ure).
 Define the competition, upgrade and replacement relations between the operator‟s own
products.
 Record the reference relation between the operator‟s own products and the
competitor‟s products.
5.2 „Product Service Offer‟ Configuration

Management Acts are defined for each B usiness Acts (like new subscription, mobile
renewal …). Each Management Act can be implemented using Product Service Offer entity
or Product Offer Service Offer entity. As a result, it is possible to charge each Management
Act. The price of the Management Acts is set per Act and per Channel.
It possible to manage specific price rules like for example: the 2 first Management Acts are
managed for free by CSR, the third on e is payable.
 Set/define the servic e offer related to the products. For example, set/define the
customer services of new installation, termination, moving, shifting and changing the
product/service of regular telephone;
 Set/define the relationship of correlative or exclusive between the customer services.

For example, the service of telephone moving will be forbidden after the service of
termination is confirmed.
 Set/define the restrictive condition between the customer service and the product
status. For example, the service of telephone moving is forbidden with the product
status is „Telephone Suspending for Arrears‟.
5.3 „Product Offer ‟ Configuration Management

A product offer is some kind of combination and package of multiple products with a series
of price plans, which is created by carriers with the purpose of occupying market and sales
promotion.
5.4 „Product Offer ‟ Configuration

 Set/define the attributes of a product offer, including : name, code, sales clause, effect
date, expiry date, etc;
 Set/define the payment met hods;
 Set/Determine dynamically the status of a product offer;

 Create a new product offer through combination of multiple products that can be
bundled, the amount, the life cycle etc.
 Create a new product offer by bundling the products of the c arrier itself and the ones of
partners;
 Create a new product offer by bundling the services of telecommunication and the
physical products.
 Supporting to acquire the attributes of the products while products are being bundled.
For example, the bundling of GSM service and ADS L with bandwidt h of 512K.
 Supporting multiple kinds of life-cycle control of the bundled products.
 Based on Usage Duration. For example, for the bundle of GSM service and ADSL,
the GSM service cannot be applied for the t ermination of the service until January
of year 2005 or after 1 year-usage.
 Based on Consumption. For example, for the bundle of GSM and ADSL, the GSM
service cannot be applied for t he termination of t he service unt il total c onsumption
reaches or beyond 100 €.
 Supporting to extend Life Cycle dynamically.
 Set/define corresponding actions while the restriction on the life cycle of bundled
products being brok en. The actions are showed as below:
 Broken forbidden
 Compens ate for breach of faith/cont ract
 Shifting of tariffs/product offer (manual or automated)
 Support to set the relevant suggestive information while the restriction of the life cycle
of a bundled product is being broken so that the relevant suggestion can be given
during order ent ry.
 Support to set the service offer attached to a product offer.
 Support to dynamic ally extend/add restrictive rules for the sale of the product offers
and to establish the combined relationships of the restrictive rules.
 Set/define the target customer relative to a product offer, to determine which customer
possesses the right to purchase this product offer. Dynamically set the eligibility criteria
of the target customer which are enumerated below:
 Customer type
 Statistic parameters of population, such as age, sex, profession,
 Capability of consumption

 Customer list - Marketing Campaign
 Customer group
 Support to set/define the allowable sales region of a product offer.
 Support to set the Product Offer channel of a product offer using Product Offer
Constraint entity.
 Support the function of „Copy & Create‟, which means a new kind of product offer can
be created by copying an existed product offer, which is already defined, and modifying
some attribut es of it.
 Support to notify the billing system to price a new configured product offer with the
means of cooperation work orders and to modify the status of this product offer as „To
be Priced‟ at the same time.
 Support to modify the information of product offers and to record the history data.
5.5 „Price Plan of Product offers‟ Configuration

Price Plan is related to Product Offer. ZTE provides web bas ed GUI to configure all the
rules of Price Plan. ZTE creates relationship bet ween Product Offer/Product/Service Action
and Price Rule by Event. Event is the component of Product: generat e by Product
Offer/Product.
There are 3 ways to generate event:
 Subscription or related action of management, generate One Off E vent
 There is cycle rules of product that has been subscribed, generate Recurring E vent
 Subscribed product in use, generate Usage E vent
Price Plan include a group of price rules to describe rating rules of event that be generated
by component of Product Offer.
It is possible to configure Management Acts (Service Offer) price calculation per different
criteria:
 Customer Profiles,
 Channels,
 Call Reasons for Customer Care
Thus it can allow to rate the Management Acts depending on the cont ext.

6 ZTE Charging Process and Capability
6.1 Usage Event Charging

ZTE OCS makes charging for session-based and event-based service in realtime. The
following Figure 23 shows the usage event charging process in ZTE.
Usage Rating Process
Online Collection
Diameter CC
SMPP 1.1 Protocol Adapter 1.2 Routing
NE Message EMPP (Decoding) (select charging server)
Raduis
Routing
Diameter CC Table
SMPP 1.3 Protocol Adapter
NE Message EMPP (Encoding)
Raduis
Overloaded
2.1 Overload Control
Preprocessing
Preprocess
Rule
Not overloaded Customer
Profile
2.3 Customer
2.2 Normalization 2.4 Sorting
Guiding
Price Plan
3.1 Session 3.2 Match Price 3.4 Price

3.5 Calculation
Rating
management Plan Analyze
3.5.4 3.5.5 TAX &

3.5.1 Price 3.5.2 Bonus 3.5.3 Benefit 3.5.6 Trigger
Accumulator additional fee
Caculation Calculation Calculation Monitor
Calculation Calculation
Account
Charging
Balance
4.1 Balance Reservation 4.2 Balance Deduction CDR file

4.3 AOC 4.4 Generate CDR
(for initial/update CCR) (for terminate CCR)
Figure 21 ZTE Usage Event Charge Process
Process description:
 Online Collection has two main functions, protocol adapter and chargi ng server routing.
By protocol adapter, ZTE supports any type of online charging messages, such as
common used Diameter Credit Control, SMPP+, EMPP, and Radius.
 Routing is to select a charging server if more than one charging servers are depl oyed.
 Preprocessing has functions of Overload control, Normalization, Customer Guiding and

Sorting. ZTE analyzes the message queue and if the queue length exceeds the
limitation which can be configured, ZTE deems it as overloaded and rejects new
coming messages to protect the system.
 Normalization is to convert the incoming event information format to ZTE internal

format, and standardize the charging attribute values.
 Customer Guiding is to match the event with customer, account, subscriber and
subscription product.

 Sorting is to classify the events to standard events required by ZTE rating engine
according to preprocessing rule.
For example, the charging event is matched as voice call, short message, data service, and
content service by preprocessing. And voice call can be subdivided into On-Net Call and
Off-Net Call. Off-Net Call if till it is fractionalized as the event types defined in the price plan.
 When enter the Rating phas e, the charging event is matched with the P rice Plan (Price
Plan Guiding) and then ZTE analyzes the Price Plan (Price Analyze) so that the event
can be rated (P rice Calc ulation).
 For session bas ed event, ZTE maintains the session for the event.
 Price Analyze: Search for price versions according to events, and select matched
charge calculation rules according to event attributes and Pric e Selector.
 Calculation: Calculate the charge, bonus, benefit, accumulation and tax of input events ;
also monitors the trigger.
 Notification: Send consumption notification to users according t o the notification rules

defined by the system
 Generat e CDR: ZTE OCS generates CDR for each call and other usage.
ZTE supports the following charge characteristics:
6.1.1 Rating Processing
There are two types of rating processes, rating for granting units and rating for updating
balance.
1 Rating for granting units:
The charging request sent to rating engine is either initial request or update request, when
received the reverse rating request, the rating engine will compute the maximum quantum
that can be authorized to customer, like max duration, volume, with reference to customer
data, service type, tariff plans and account balances and return the granted service units.
2 Rating for updating balance
If there comes the charging request for service termination, similarly, the rating engine will
rate the final price with reference to customer data, service type, termination cause (e. g.
session timeout, user logout, authorization expired, etc.), service initiated time, resource
consumed, and customer accumulation to update customer account balanc e, bonus points
and accumulation.
The reverse rating result (interim rating result) may be different with the final rating result for
service termination, because some of the factors that affect the service delivery and rating
criteria can only be available after the service session, the factors like: the exact service
delivery time, exact dat a traffic volume. In this case, the reverse rating result can only make
the estimation of the charging request; however, the final rating res ult will be used to update
customer account balances.

6.1.2 Rating Criteria
The criteria of Rating will be able to result from the event to develop, information of
customer, the offer of the customer or to be calculated by the system.
Rating is able to be done according to multiple criteria (time, volume, recipients …).
ZTE identifies the customer‟s and product‟s attributes by event properties that can be
predefined or extended by the operator. The event properties can be used as rating criteria.
The event property includes static property and dynamic property. The static properties are
the ones that have been predefined in the system, while the dynamic properties are the
ones that can be defined by the operator to extend the rating criteria.
For example, the payment attribute (prepaid or postpaid) and the max number of Family &
Friend number are static properties; and the customer‟s birthday and occupation are
dynamic properties.
Figure 22 Example of Definition of Event Attributes in ZTE*
As shown in the above Figure 24, the UI of event properties, ZTE can define event
properties for the incoming charge events. Also it can create new event propertie via UI.
Both static and dynamic attributes are referenced for rating. The option Measurable
specifies whether an attribute can be used as Price Unit and it can be set to YES only for
attributes of data type.
In ZTE system, price adaptation is able to be set in line with customer con sumption over
the cycle, please refer to chapter Meters.

The configuration of Rating Criteria undergoes 3 phases in order to support the execution of
rating rules in ZTE Rating/ Charging as shown in following Figure 25.
ODR
Preprocessing
Sort Rules Normalization
Rule Filtering
Customer&Guiding
Sorting
Sorting
IDR Include additional information

(Rating criteria) for rating
Subscription Data
Match Price Plan

Price Analysis
Price Analysis
Mapping Rule
(Price Selector)
Calculation Rule
Price Calculation
Figure 23 3 Phases to Support Execution of Rating Rules in ZTE Rating Engine
 Normalization/Customer Guiding/Sorting: Preprocessing Rules are defined through the

configuration int erface, producing rating criteria on recognizing the event type.
The following Figure 26 is one of the preprocessing flow configuration interfaces which
show the processing steps.
Figure 24 Example of ZTE Preprocessing Configuration*
 The following Figure 27 shows one of steps in configuration interface in above figure. It
can implement the configuration of all conditions of each step, including export of event
type. „Rule Expression‟ is used to configure existing combination of logic expressions.
The detailed option can be selected in 'Expression'; The option of 'Result ' allows user
to add or modify the attribute value of present billing event, but this rule is available
only when the return value of 'Rule Expression' is true. For example, ‟Rule Expression‟
is used to estimate call distanc e and new dynamic attribute will be added in “Result” as
the expression calculation result.

Figure 25 Example of Defining a step of preprocessing flow*
 Match Price Plan & Price A nalysis: First, finding subscriber‟s price plan through looking
up customer data. Then, next step is matching the rate plan by event type. Price
Analysis selects exact rating methods according t o Mapping Rule if the rate plan has
configured ZONE MAP.

Figure 26 Example of ZTE ZONE MAP Element*
In Figure 28, we can find Zone Map element on the interface, it is a kind of table that can
contain any data presentable in data list format, e.g. country region, peak hour/ off-peak
hour, special numbers made by operat or or public holidays without fixed dates (for example
Easter day every year). The mapping tariff plan can apply to all products regardless of
offers and options.
 Price Calculation: supporting various types rating criteria like linear, non-linear, time
span based, accumulation based, and Python script based. The interface provided by
rating engine can be used by Python script to acquire attributes in database as rating
criteria.
6.1.3 Rating Parameters
The system provides charging by the call duration (minute, second) of voice or dat a service,
charging for SMS, MMS or content download, and flow based charging.

Figure 27 Example of ZTE Rating Parameters *
As shown in the above Figure 29, the purple oval part indicates optional attributes, the red
oval part indicates price unit. The above fi gure specifies the rule of “0. 50 Euros per 60
seconds”
 Rate Unit
 Charge by the duration
 For voice or data service, the system provides duration -based (minute, second)
charging modes.
 Charge by the event
For SMS, MMS or download servic e, the system provides event-based charging modes.
 Flow based charging
For data service, the system provides flow-based charging modes.
It could be based on uplink flow, downlink flow or both uplink flow and downlink flow.
 Charge by the content
The system provides charging by the content.
 Combinational measurement
For one usage of users, the system provides the combinations of multiple charging
measurement modes, for example, combined charging by event and by duration
 Measurement units
The system provides multiple measurement u nits
 Measurement units of duration
The charge unit may be N*1/1,000 second or N*second. N is any positive integer.
 Measurement units of flow
The charge unit may be N*Bytes, N*Kbytes or N*Mbytes. N is any positive integer.
 Measurement units of cont ent
The charge unit may be the amount of content.
 Quantum
As showing in above graph, Quantum (Calculation Unit) can be regulated flexibly.
Quantum can be any integer.
 Price of Rate Unit

Price can be any values, including plus, negative, decimal fraction, integer...
The currency type is optional
 Indivisable
If the subscriber„s usage can not be divided exactly by Quantum (Calculation Unit), the
result will be up rounded
 One event can be used for calculating more than one charge. That is implemented by
E vent -RatePlan in Price Plan. As shown in the following Figure 30, Local Call E vent
can serve as two charges: Local Call Fee and Access Fee.
Figure 28 One Event More Than One Charge*
 The calculation of tax and additional fee can be defined in Pric e Plan.
The calculation of several types of tax and additional fee on one event is supported in
system.
6.1.4 Price Calculation Method
1 Basic Tariff
For example : 0.10euro/min
2 Time Span Price
For example: 0.40euro/min during peak time, 0.20euro/min during off -peaktime

Figure 29 Example of ZTE Price Calculation Methods *
Tariff depends on the time when users us e service, for example, busy hour, idle time and
holidays;
As shown in the above Figure 31, ZTE supports special rates for holidays and special time
periods. The red rectangle at the left bottom cor ner in the above figure shows the rules
related to time periods. Starting Dat e and Cycle define the attribute Calendar, Starting Time
and Duration define the attribute Time Span. The example in the above figure sets the
Cycle to 1 week and the Starting Date to “2007-04-21”. It means that the cycle starts at
00:00: 00(Starting Time is 00:00: 00) on Saturday (2007 -04-21 is Saturday) with t he duration
of 48 hours (Duration is 48 hours). In other words, the segment defines the time periods
from 00:00:00 on every Saturday to 24:00:00 on every Sunday.
Calendar-bas ed dat e definition
 Week
The validation period of rules is the recurrent date every N (N>=1) week(s), for example,
every Sunday.
 Month
The validation period of rules is the recurrent date every N (N>=1) mont h(s), for example,
th
the 15 of every month.
 Year
The validation period of rules is the recurrent dat e every N (N>=1) year(s ), for example,
st
January 1 of every year.

 Specific time
For example, May 17, 2008;
 Definition of time segment
A time segment may be any period of a day. Its accuracy is second.
 Combinational validation rules
In a price plan, multiple rules for calendar and time segment tariff can be defined. If a tariff
becomes valid within multiple calendar time segments, the applied rules could be:
 the applied rules could be the rule with highest priority
 those that could be superimposed
The definition of Customization Calendar and Span: the new Calendar and Time Span can
be defined in each Price Rule, Thus, the subscriber can obtain the specific defi nition of
Calendar and Time in P rice Rule which mapped t he Price Plan Parameter chosen by
subscriber.
One issues we should address is overlapped call communication, i.e. the call taken place
over two different calendar period, we are able to rate with both initial tariff of the call
beginning and separated tariffs in different time span via configuration.
3 Rank Rate
For example: In one call,0.20euro/first 3 min, thereafter 0.10euro/min
The system provides segmented meas urement charging modes.
In the rank rate:
 Multiple segments can be defined for one event. No limits on the number of segments.
 The Segment conditions are based on all price units.The Calculation unit can be
redefined for eac h segment and charge rat e can be redefined for eac h segment.
 The segment can be calculated by fixed rates and the percentage of original rate.
 When Rank P rice is defined, the time will be divided into different segments for charge
calculation according to segment rules.

Figure 30 Example of ZTE Rank Price Configuration*
As shown in the above Figure 32, the Rank Price rule at the right bottom corner defines two
RankPric es: the first 300 seconds will charged according to the first RankPrice („5 Euros per
300 seconds‟), the time segment bet ween 300 and 3000 seconds will be charged acc ording
to the second RankPrice. The time that exceeds 3000 seconds will be charged by applying
the Basic Price rule (0. 50 Euros per 60 seconds).
4 Accumulation Price
The accumulation counters will be used to accumulate the servic e usage for some or some
specific events, for example: free for first 100 minutes call, then above the thres hold
0.20euro/min
5 Expression Price
With the support of the Python script, we enable the customer much more flexibility to
define complex rating logics, e.g. the rating logic can be based on the customer gender,
customer birt hday, customer occupation, etc.
Several Algorithms compounding, the priority of rating rules can be defined.
Price can be explained in many balance types (resource type), and the priority of balance
type rating can be regulated.
6.1.5 Rating Output
There are 6 types of rating results that can be generated by rating engine, separately they
are: Price, Tax & Additional Price, Accumulator, Bonus Points, Benefit and Trigger.

1 Price
The calculation of the charging event cost.
2 Tax & additional Price
Exclude the generic cost of the event, the carrier can apply additional tax base on the
original cost, then carrier can define tax & additional fee.
The rating engine supports the calculation of multi taxes and price on one input event, while
taxes and prices will be stored separately.
3 Accumulator
Accumulator is to define the way of accumulating a variable in SDP. With an accumulator,

SDP can automatically accumulat e a variable and write the result to the accumulation t able
in the memory database. The accumulation result can further be used to calculate the
Accumulation Price or used for other applications, such as the Accumulation Trigger.
4 Bonus Points
To encourage the customer using the services, the carrier usually makes promotion by
bonus points. The bonus points are calculated according to some rules for some service
usage. For example, give 100 points for every RMB 100 usage; or increase N points for
each 1 year subscribed in the carrier‟s net work. These bonus points can exc hange usage
fee or gifts, etc. For the bonus points exchanging rule, please refer to B onus Exchange
Rule Management
The ZTE system calculates user bonus by using the same rating engine as it does usage
charge.
Bonus calculati on rules are included in the price plan. Users may order bonus calculation
rules as they do a price plan.
Bonus calculation rules may be based on users‟ usage charge events, recurring charge
events, and one-off charge calculation events.
The measurement of bonus and t he flexibility of calculation are the s ame as those of usage
charge calculation.
Here, in Figure 33 we can find the detailed bonus calculation criteria in ZTE:

Figure 31 Example of ZTE Bonus Configuration*
The bonus calculation is also on basis of event calculation. We have defined 3 types of
bonus type in the system: Credit bonus, Consumption bonus and Loyalty bonus. Each
bonus calculation event is associated with product or offer.
The bonus calculation plan is also limited with effective date, expiry date, and the
calculation unit is also various, it can occurrence, duration, etc.
5 Benefit
Benefit means that in a specific case, operators award to end users a s pecified type of
resources: balance or free usage;

Figure 32 Example of ZTE Benefit Configuration*
The above Figure 34is the UI for configuring benefit rules which include: calculation rule,
type, period and limitation on benefit usages.
 Benefit Type
Benefit resource types include, but are not limited to:
 Balance
It can be subdivided into the balanc e used for some service consumption;
 Voice call duration
It can be subdivided into the duration of a specific service type, for example, local r eceiving
duration
 Data download flow
 Cont ent times
 Benefit creation
The trigger conditions of benefit may be the following:
 Order
 Periodic trigger
 Accumulation or balance threshold
 Benefit valid period
 Immediate validation, fix ed expiration time
For example, the validation time is the current day and the validation period lasts till the end
of the current month
 Delay ed validation, fixed expiration time
For example, the validation time is next month and the validation period is three months
 Multiple validation periods:
For example, one benefit is divided into 10 validation periods;
 Usage Constraint of Benefit
We may define usage constraint for benefit resources:
 Cons umption amount limit
Maximum amount of periodic usage
Maximum amount of daily consumption

 Service type limit
Benefit resources can only be applied to specific service types
 Usage priority
Different benefit types have different priorities. The rating engine will first use high-priority
benefit resources.
If the same type of benefit resources is pres ented at different points of time, the benefit
resources presented first will be used first.
6 Trigger
Trigger is used to activat e some actions when accumulation or balance reaches a thres hold.
Such actions can be giving benefit, sending message, one-way block, and so on. The
operator can set the threshold for accumulation and balance, and also the actions triggered
by the threshold. Upon the accumulation or balanc e reaching the threshold, the actions are
carried out.
Trigger in ZTE falls into two types:
 Accumulation Trigger
The actions are triggered by increment or dec rement of accumulator.
 Balance Trigger
The actions are triggered by increment or dec rement of balance.
6.1.6 Typical Business Scenarios
1 Calling / Called Party Based Rating
 Distance-based charging
The system provides the charging modes based on the relative distance between the c aller
and the called, for example, international toll call, domestic toll call, and local call.
The system supports multiple classification modes in a single system.
 Roam charging
The system provides the judgment of customer‟s home location and conversation place.
Roaming can be treated as services delivered to customer in different city, or region other
than the requested place.
 Specific case of same city
When a roaming caller dials the number of the roaming plac e or another roaming number at
the same place, the caller may enjoy different tariffs;
When a roaming called receives the call from the roaming place or another roaming number
at the same place, the called may enjoy different tariffs.

2 Favorite Number (F&F)
Users may define as favorit e numbers some numbers they often dial. They may enjoy
premium tariffs when dialing these numbers or receiving the calls from them.
Favorite number premium rules can be applicable to specific service types, such as caller
conversation, callee conversation and short message.
Number match principles:
 Accurate match: The designated number list is a complete number
 Number initial match: The designated number list is a number initial (area code), and
the number prefix to be matched is able to be configured in preprocessing rules with
specific lengt h.
Users may have an unrestricted number of favorit e numbers.
3 Close Us er Group (CUG)
An organization may have a large number of internal conversations, which may enjoy a
premium tariff. Us ers may enjoy this premium tariff by dialing a short number or defining a
CUG in a charging system.
 Realize a CUG by means of network
An NE is used to define a CUG and translate a short number. In convers ation records, it
indicates that the current conversation is a CUG conversation.
 Define a CUG in a billing system
An NE does not manage a CUG, whose member information is recorded in the charging
system. From a CUG member list, the charging system judges whether the current
conversation is a CUG conversation.
 Management of CUG
The system supports the addition, modification or deletion of CUG information.
The same organization can have multiple CUGs.
One user can join more than one CUG.
Different CUGs may benefit different call charge.
For the conversations between two users from different CUGs, the system matches correct
call charge according to priority.
In the system, multiple CUGs may form a larger CUG. That is, the members of a CUG are
CUGs.
4 Location Bas ed Price
In the system, when a user has a conversation within a designated ar ea (“premium cell”),
for example, when a student has a conversation within a school, he may enjoy a special
tariff.

 The caller within a premium cell
 The callee within a premium cell
 A user within a premium cell calls another wit hin this cell
 A user within a premium cell receives a call from anot her within this cell
5 Cross Bundle Price
Bundle price means that multiple different users are bundled to enjoy a special tariff.
 For ex ample, operator may offer bundle discount on Mobile and ADS L. If a customer
subscribes these two products, s/he may apply for the bundle discount. The rule for
this bundle discount could be: The rate of A DSL will have 50% discount off if the
usage of Mobile reaches to 150 Euros in one month. To realize this feature in ZTE, the
Product Offer needs to be defined with the type of Bundle Offer, which should include
an Offer price plan that in turn defines that discount rate of ADS L refers to the
accumulated usage of Mobile.
 Bundling may be based on the same or different products
 There may be a random number of bundled products
 The bundled products may have respective charge rules.
 For example, A and B, two same product type instances (users) can be
bundled, but may have different call charge.
 Reference premium
 Cross reference premium can be offered among bundled products. When

multiple instances are bundled, reference premium may be designated for a
specific member
 Share accumulation
 Bundled members may own common accumulation, which is used for, for
example, the bundle-based total premium rule.
 If the bundling relationship is unbound, so will its corresponding charge rule.
6.2 One-off Event Charging

The following Figure 35 shows a typical One-off event processing flow.

One-off Fee Process
(CRM Order
1.2 One-Off 1.4 Order 1.5
Entry)
1.1 Action Change 1.3 Display Price Notification
UIP
User Input Event Generate Confirmation
Customer
Profile
Preprocess
Preprocessing
Rule
2.2 Customer
2.1 Normalization 2.3 2.4 Sorting
Guiding
Price Plan
3.1 Price Plan

3.3 Price Analyze 3.4 Calculation
Guiding
Rating
3.4.4 3.4.5 TAX &

Charging
4.1 Balance
Deduction
Account
Balance
Figure 33 ZTE One-off Event Charge Process
One-off event is triggered by CRM Order E ntry which not belongs to OCS in most cases.
ZTE OCS interfaces with CRM by UIP (Unified Interface Platform, a component of ZTE ).
UIP receives action information from CRM and generates a one -off event to be rating.
1 One-off E vent Generate: Generate event attributes necessary for one-off charge
calculation and send them to the rating engine for charge calculation.
The chargeable event attributes generated by Order Entry include, but are not limited to:
 Customer information
 Order information
 Channel information
 Anything optional in the customer order interface
 Display Price: The rating result is returned to CRM and Displayed to customer.
Display information includes:
 Charge
 Tax & Additional Fee
 Bonus

 Accumulation
 Benefit
2 Order Confirmation: Confirm the calculated price and collect charge from customers.
Collect charge directly or consolidate it to a usage charge bill. The confirmation and
charge collection is done by CRM
3 Preprocess: Generate the chargeable events required by the Rating Engine based on
the original chargeable events created by Order Ent ry. Necessary supplementary
attributes will be c reated in t his process. In this process, normalization, Customer
Guiding and Sorting take the same functions as those of usage event process.
4 Rating: Calculat e charge by the same flow as usage event rating.
5 Charging: The rating result is return to CRM for displaying and confirmation. Upon
receiving request of balance deduction. ZTE deduct the balance from the account
balance.
The ZTE product supports the following one-off charge calculation characteristics:
6 Mechanism: Same data model and Rating Engine are used for one-off charge as
usage charge
7 Rating reference attribut es: criteria
 Customer information
 Gender
 Age
 Profession
 Etc.
 Order information
 Order parameters
 Channel information
 Distributor information
 Self-c are
 CSR information
 Anything optional in the customer order interface
Rating reference attributes can be extended as required. The rating engine supports
dynamic addition of rating reference attributes
8 Charging results
 Charge

 Bonus
 Tax
 Accumulation
 Benefit
 Trigger
6.3 Recurrent Event Charging

Periodic charging is triggered by the Time Schedule module. By scanning order data, ZTE
generates the periodic chargeable events to be currently calculated, which will be
processed by the rating engine. The Figure 36 shows the recurring event process.
Recurring Fee Process
Preprocessing Generate Event
Time
1.2 Subscription 1.3 Recurring Event
Schedule 1.1 Get Run Task
Data Scan Generate
Customer
Profile
Preprocess
Rule
2.2 Customer
2.1 Normalization 2.3 2.4 Sorting
Guiding
Price Plan
3.1 Match Price

3.3 Price Analyze 3.4 Calculation
Plan
Rating
3.4.4 3.4.5 TAX &

4.1 Balance CDR file

Charging
4.2 AOC 4.3 Generate CDR

Deduction
Account
Balance
Figure 34 ZTE Recurring Event Charge Process
1 Get Run Task: Get the periodical type of the current processing according to Time
Schedule
2 Subscription Data Scan: Filter the subscription data to be processed according to a

periodical type
3 Recurring E vent Generate: Generate periodic chargeable events according to the

subscription data and the periodical type
4 Preprocess: Generate the chargeable events required by the Rating Engine based on
the chargeable events generated in previous step.

5 Rating: Calculat e charge
6 Charging: Deduct the charge result from the account balance; send AOC to customer if
configured; and generate CDR for this recurring event rating.
ZTE supports the following periodic charging characteristics:
7 Same dat a model and Rating Engine are used for rec urring charge as usage charge.
8 Flexible period types
 Month: One or more months
 Day: One or more days
 Week: One or more weeks
 Year
For each period type, the start time of a period may vary with each order.
Different products in one Offer have different calculation periods;
The calculation period of recurring charge may be different from users‟ account period.
9 The charging method for recurring event falls into 4 types: Cycle forward charging,
cycle fold charging, every day (pro rata charging) and variable cycle. When s electing
prorated charging, the recurring fees will be charged in ac cordance with actual
consumption period.
10 The first period and the last period can be accurately calculated according to actual
proportion of usage time
11 Referenc e attributes of recurring charge calculation
The reference attributes of recurring charge calculation include, but are not limited to:
 Customer data
 User order data
 Users‟ charge options
 Time
 Dynamic attributes calculated by Preprocess according to a reference table
12 Special calculation of us ers‟ usage state
For example, no recurring charge will be charged after a user has reported his loss of SIM
card
13 Charging results
 Charge

 Bonus
 Tax
 Accumulation
 Benefit
 Trigger
6.4 Meters
The business rules related wit h Counter is implemented though Accumulation & Account
Balance in ZTE.
Account Balance is the resource which can be consumed by subscriber in his account,
including amount type resource and free resource.
Accumulation is a counter defined in system, recording the current accumulation

information group by classification.
Account Balance and Accumulation are changed dynamically according to the subscriber
usage. Account Balance will decrease while the subscriber usage is increasing, than
Accumulation will go in opposite direction.
6.4.1 Accumulation Type
The above figure is the UI for configuring Accumulation type. Accumulation type can include
the following optional items:
1 Period of accumulation
 Day: The accumulation period is one day
 Week: The accumulation period is one week and starts with zero
 Month: The accumulation period is one month and starts with zero
 Year: The accumulation period is one year and starts with zero
 Variable period: It may be permanent accumulation or a dynamic time segment.

Application determines the time segment for accumulation
2 Accumulation Hierarchy
 Subscriber accumulation: Accumulate one subscriber‟s accumulated values
 Customer accumulation: Accumulate one customer‟s accumulated values
 Bundle accumulation: Accumulate any accumulated values with a bundling relationship

 The fee produced by one event can be accumulated repeat edly into different
Hierarchies.
3 The fee produced by one event can be accumulated repeat edly into different
accumulation types.
6.4.2 Accumulation Rule
Accumulator can include the following optional items:
1 Accumulation trigger mode of accumulation
 Usage charge event trigger
 recurring charge event trigger
 One-off event trigger
2 Cumulative event attribute
The system supports the accumulation of the measurable attributes of an event, which
include:
 Duration
 Times
 Charge: One or more charges caused by an event
 Flow: uplink, downlink
3 Accumulation measurement unit
The system supports a measurement unit similar to tariff. For example, 5-second duration
or 2K flow can be taken as an accumulation unit;
4 Different accumulation rules can be defined for different user groups. Accumulation
rules depend on t he use of accumulation. Generally, accumulation is used by charge
rules; therefore accumulation rules are also part of a price plan.
6.4.3 Usage of Accumulation
Referenc e of charge rules:
Accumulation can be reference by Preprocess, Charge Rule Match, Tariff Calculation or

Premium Calculation.

Figure 35 Example of ZTE Accumulation Price Configuration*
The above Figure 37 is the UI for configuring Price using Accumulator as reference. For a
price rule, specific rate („Price‟) can be set based on „accumulation type‟ and accumulation
duration („From…To‟).
6.4.4 Threshold
Accumulator or Account Balanc e can include the following thresholds features:
Figure 36 Example of ZTE Accumulation Trigger Configuration*
1 Triggers notification:
When accumulation or account balance exceeds a preset threshold, it will trigger short
message notification.
2 Triggers benefit

When accumulation or account balance exceeds a preset threshold, it will trigger a benefit
event.
3 Triggers other operation
When accumulation or account balance exceeds a preset threshold, it will trigger a credit
control operation or generate ot her event that can be proc ess by the system.
6.5 Price Plan

An event is rated according to specific Price Plan. Price Plan can contains the elements
shown in Figure 39.
Figure 37 ZTE Price Plan Elements
The following rules can be defined in Price Plan:
 Price,
 Bonus: Loyalty Point,
 Tax,
 Accumulation: Count er,
 Benefit

 Trigger
According to different effect, Price Plan can be divided int o several types, as following:
 Subscriber Default Price Plan: This kind of Price Plan defines rating rules for all
events that could be generated by component of Offer. It will take care of a event if it is
not specified in other high-priority Price Plans.
 System Default Price Plan: It can take effect without subscriber‟s order. This kind of
Price Plan usually only defines special rating rule in special time p eriod for some
special event, e.g., discount of local call on Christmas day, valid for all subscribers or
all subscribers meeting the required Eligi bility Rule (targeting customers), defined in
this System Default Price Plan: it is a usually named as a Promotion. The priority to
use different applicable P rice Plans is defined in each Price Plan, allowing full control
on discounts application sequence.
 Individual Price Plan: This type of P rice Plan allows, using relevant priority, to
override the 2 preceding Default Price Plan types. For example: when one subscriber
join a Promotion which specifies some special tariff of On-Net Call (On-Net Call
standing for call bet ween two operator mobile net work ), all default P rice Plan can be
disabled. The priority to apply different applicable Price Plans is defined in each Price
Plan, allowing full control on discounts application sequence.
 Di scount Price Plan: This kind of Price Plan is similar to ‟Individual Price Plan‟ except
that a discount price plan is used as a supplemental to the existing price plan and will
not override the others. For the same example mentioned previously: this time, the
rule is more 20% discount on On-Net call.
 Offer Price Plan: This kind of Pric e Plan is used when more than one main product
are involved in a bundle. Rules in such kind of Price Plan may refer to each other. For
example: rule A refers to rule B based on accumulation of local call. If local call
accumulation of B is more than 100, then recurring charge of A will be had a discount
of 50% off.
ZTE allows configuring flexible rating rules by parameters configuration. The method is
shown as follows:
 Version: rating rule can be divided to versions by different time period. For any required
changes on rating rules, create a new version of rating rules instead of modifying the
old rules. The new version of rating rules and the effective and expiry time of these
rules can be configured on GUI.
 Parameter: an alternative way to customize the rule besides using P rice Plan. For
example, set Order Ent ry for order discount rate.
 Zone Table: manage and configure mapping table of voice call zone code and category
rule, and content service URL rules etc by tree structure.
 Mapping: according to the attributes of rating request, use mapping t able t o get related
rules. For ex ample, mapping by occupation of customer.

 Time Span: define calendar or time period related rating rules.
 Accumulator: Accumulator cumulates the usage of subscriber, and the result is quoted
by rating rule.
 Rank: for rank tariff. For example, first 3 minut es rating in 0.1Euro/min, switching to
0.05 Euro/min for the period of 3 to 10 minutes, then after that every 30 s econd is 0.01
Euro.
 Python Script: specify rating rule that cannot be configured by expression in Python.
 Decision Tree: according to the attributes of rating request, try to match the combined
conditions defined by decision tree.
7 ZTE Extendibility to Convergent Pre-

postpaid System
The design and implementation of ZTE are modularized; the following figure 40 shows the
entire functional software packages (modules) of ZTE.
ZTE OCS solution consists of the packages in blue color.
From the view of software, by extending the packages in yellow colors, the Customer Care
and Offline Billing can be implemented, and then the OCS charging system evolves to
prepaid and postpaid converged billing system.
Further more, by adding Marketing & Sales Management, CRM is ready; by integrating the
packages Order Management, Service Problem Management, and Workforce Management,
ZTE can build a Trouble Ticketing and Service Provisioning system.
Customer Contact Management
Marketing & Sales

Customer Care Revenue Management
Management
Account
Channel Inventory Customer Product
Balance Invoicing
Management Management Management Management
Management
Service Problem
Order Management Charging Settlement
Management
Provisioning Workforce Service Voucher

Mediation
Management Control Management

Figure 38 Overall Functional Packages of ZTE Suite

2.3.2 ZTE OCS OCU Product Description

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2.3.2 ZTE OCS OCU Product Description

Uploaded by

Copyright:

Available Formats

ZTE OCS OCU

Version Date Author Approved By Remarks

V4.10 2012-08-12 Not open to the Third Party

© 2012 ZTE Corporation. All rights reserved.

ZTE Confidential Proprietary © 2016 ZTE CORPORATION. All rights reserved. 1

3 ZTE OCS Hardware Structure.................................... Error! Bookmark not defined.

4 ZTE OCS Software Structure ............................................................................ 19

5 ZTE Concept Model .......................................................................................... 43

6 ZTE Product & Offer ......................................................................................... 49

7 ZTE Charging Proce ss and Capability ............................................................. 55

8 ZTE Extendibility to Convergent Pre-postpaid System .................................... 81

ZTE Confidential Proprietary © 2016 ZTE CORPORATION. All rights reserved. 2

Figure 1 OCS Location in the Network ....................................................................................... 9

ZTE Confidential Proprietary © 2016 ZTE CORPORATION. All rights reserved. 3

Table 2 P roduct Domain Entities .............................................................................................. 44

ZTE Confidential Proprietary © 2016 ZTE CORPORATION. All rights reserved. 4

AAA Authentication Authorization Accounting

AoC Advice of Charge

APN Access Point Name

BCF Bearer Charging Function

BSS Business Support System

CAMEL Customized Applications for Mobile Network Enhanced Logic

CAP CAMEL Application Part

CCA Credit Control Ans wer

CCG Cont ent Charging Gateway

CCR Credit Control Request

CDF Charging Data Function

CDR Charging Data Record

CP Cont ent Provider

CSI CAMEL Subscription Information

CSIP Convergent Service Interface Processor

CSCF Call Session Control Function

CSR Customer Servic e Representative

CTF Charging Trigger Function

CUG Closed User Group

DCC Diameter Credit Control

EBCF E vent Based Charging Function

ECF E vent Charging Function

EMPP Extensible Messaging and Presence Protoc ol

FR Formatting and Routing

FTAM File Transfer Access Management

FTP File Transfer Protoc ol

GGSN Gateway GPRS Support Node

GMLC Gateway Mobile Location Center

GPRS General Packet Radio Service

GUI Graphic User Interface

HLR Home Location Register

HTTP Hypertext Trans fer P rotocol

IDR Interim Detailed Record

IEC Immediate E vent Charging

IMS IP Multimedia core network Subsystem

IMSI International Mobile Subscriber Identity

INMI Integrated Network Management Interface

ISMP Integrated Service Management Platform

ISC IMS Service Control

ISDN Integrated Services Digital Net work

ISMP Integrated Service Management Platform

LCS Location Services

MML Man-Machine Language

MMS Multimedia Messaging Service

MSC Mobile Services Switching Centre

MSISDN Mobile Station ISDN number

MAP Mobile Application Part

ZTE Confidential Proprietary © 2016 ZTE CORPORATION. All rights reserved. 6