Charging Solution Description

1 PURPOSE AND SCOPE.....................................................................................................................................................3

1.1 Network topology.........................................................................................................................................................3
2 ERICSSON CHARGING SYSTEM..................................................................................................................................4
2.1 Introduction...................................................................................................................................................................4
2.2 Charging System Network Elements............................................................................................................................5
2.2.1 Service Data Point (SDP Prepaid)...........................................................................................................................6
2.2.2 Administrative System (MINSAT).............................................................................................................................8
2.2.3 Charging Control Node (CCN)................................................................................................................................9
2.2.4 Interactive Voice Response System (XML-IVR).....................................................................................................10
2.2.5 Account Information and Refill System (AIR)........................................................................................................12
2.2.6 Account Finder (AF)..............................................................................................................................................14
2.2.7 Voucher Server (VS)...............................................................................................................................................14
2.3 Associated network elements......................................................................................................................................15
2.4 Machine-Machine (M2M) Interfaces..........................................................................................................................17
Any Time Interrogation (ATI)........................................................................................................................................................... 19
Unstructured Supplementary Service Data (USSD)..........................................................................................................................19
Unstructured Supplementary Service Data (USSD)..........................................................................................................................19
Mobile Number Portability (MNP)...................................................................................................................................................20
File Transfer Protocol (FTP)..............................................................................................................................................20
Customer Administrative Interface (CAI)............................................................................................................................20
Administration Communication Interface Protocol (ACIP)................................................................................................21
User Communication Integration Protocol (UCIP)............................................................................................................21
XML/HTTP..........................................................................................................................................................................21
2.5 Signalling....................................................................................................................................................................22
2.5.1 HSSL and SIGTRAN...............................................................................................................................................23
3 OFFERED CHARGING SOLUTION FOR TELCO X.................................................................................................24
3.1 Dimensioning Figures.................................................................................................................................................24
3.1.1 Proposed Network Architecture..............................................................................................................................24
3.1.2 SDP.........................................................................................................................................................................24
3.1.3 CCN........................................................................................................................................................................25
3.1.4 AIR..........................................................................................................................................................................26
3.1.5 VS...........................................................................................................................................................................27
3.1.6 MINSAT..................................................................................................................................................................27
3.1.7 Summary.................................................................................................................................................................27
3.2 Offered Features..........................................................................................................................................................28
3.3 Services.......................................................................................................................................................................43
3.3.1 Airtime Transfer.....................................................................................................................................................43
3.3.2 SACC (Service Aware Charging Control) 3.0........................................................................................................43
3.4 Business Processes......................................................................................................................................................44
3.4.1 Subscriber Provisioning.........................................................................................................................................44
3.4.2 Postpaid to Prepaid process and visa versa...........................................................................................................47
3.4.3 Forced Disconnection............................................................................................................................................49
3.4.4 Voucher Provisioning.............................................................................................................................................49
3.4.5 Voucher creation, loading and status change.........................................................................................................50
3.4.6 Voucher Loading....................................................................................................................................................52
3.4.6.1 Voucher Batch Input File...............................................................................................................................................52
3.4.6.2 Voucher Batch Report File.............................................................................................................................................54
3.4.7 Voucher State change.............................................................................................................................................55
3.4.7.1 CS3 Voucher State and Lifecycle...................................................................................................................................55
3.4.8 Subscriber LifeCycle..............................................................................................................................................57
3.5 Account Structures in Charging system......................................................................................................................59
3.5.1 Account Refill.........................................................................................................................................................62
3.6 End-User communication...........................................................................................................................................62
 3.6.1 Account Refill.........................................................................................................................................................62
3.6.2 Balance Inquiry/Notification..................................................................................................................................63
3.6.3 Charging System initiated voice announcements...................................................................................................63
3.6.3.1 Call Set-up Announcements...........................................................................................................................................63
3.6.3.2 In-Call Announcement...................................................................................................................................................64
3.6.3.3 End-of-Call Announcement...........................................................................................................................................64
3.6.3.4 Mandatory announcements............................................................................................................................................65
3.7 Charging......................................................................................................................................................................66
3.7.1 Charged Services....................................................................................................................................................66
3.8 Customer Care.............................................................................................................................................................67
3.9 Reports........................................................................................................................................................................69
3.10 DR and CDR generation.............................................................................................................................................69
3.11 Roaming......................................................................................................................................................................71
3.12 O&M Procedures........................................................................................................................................................72
3.13 License Management..................................................................................................................................................73
3.14 Fault Management.......................................................................................................................................................73
4 TERMINOLOGY..............................................................................................................................................................75
5 REFERENCES...................................................................................................................................................................77
1 Purpose and Scope
The purpose of this document is providing a high level description of the
different functionalities that will constitute the Ericsson Charging System 3.0
(CS3.0) solution for TELCO X .

Description of functionalities and sub-systems included in this document may

vary in future depending in the decisions taken during negotiation phase.

1.1 Network topology

Find below overview description of each main element on the network:

MSC Server: Ericsson

Media GW: Ericsson

BSC: Ericsson BSC

HLR: Alcatel HLR

SGSN-GGSN: Ericsson

SACC: Ericssson

MMS-C: Ericsson

SMS-C: Huawei

RBT: Huawei

Ericsson Charging System will be used for real-time charging of the services.

Ericsson Charging System is capable to charge all cases for postpaid and
prepaid subscribers but postpaid business processes and rules need to be
discussed with the Customer to fulfill the business requirements.

2 Ericsson Charging System

2.1 Introduction

Charging System is a cost-efficient charging solution suitable for operators

with up to 32 million subscribers.

Charging System makes it possible for a network operator to charge in real-

time for events and sessions in the mobile network. These events and
sessions can for example be voice calls, Short Message Service (SMS) or
events using General Packet Radio Service (GPRS). It is also possible to
allow service authorization and service-aware charging including session
control.
 Each subscriber is connected to an account, which can be refilled, for
example, by using a voucher.

With the decoupling of the traffic flow from the administrative system, the
operator is provided with a clean administration- and provisioning interface,
Facilitating the integration with business-support systems.

Charging System is constructed as a decoupled architecture for all market

segments with highlights like Subscriber Segmentation Service Offerings,
Subscriber Segmentation Account Group Identity, Community Charging and
Enhanced End of Call USSD Notification.

Powerful tools for tariff management, market segmentation, bonus- and

loyalty programs, as well as for statistics generation are provided, and will
enable TELCO X to:
Increase revenue from existing services
Create revenue from new services
Stimulate usage
Strengthen competitiveness

See System Description Charging System 3.0, in CPI Library for further
general information.

2.2 Charging System Network Elements

Below diagram shows general Charging System elements.

In the figure below Ericsson Multi Mediation is shown in different colour

because TELCO X is not yet decided to include it. But in any case a
mediation system should be in the total solution in order to handle CDR
collection, formatting and distributing it to post-processing system. EMM can
also handle postpaid roaming cases by processing TAP files using ERS
(Ericsson Roaming Solutions) module on it.
So that, final diagram could change depending on decisions taken after this
document is delivered.
 Figure: Ericsson Charging System elements

Charging System consists of the following network elements:

2.2.1 Service Data Point (SDP Prepaid)

The SDP network element contains the database with subscriber and account
information. The traffic functions of the SDP include rating of calls and events,
post-processing of Call Detail Records (CDR), and initiation of USSD- and
SMS-notifications. The SDP also provides the evaluation logic required for the
call-control performed by the SCP or CCN. SDP is also used to trigger the
setup of a USSD Call-back Call.

The SDP holds and administers the following data:

Subscriber and Account data

Service Class data
Announcement Class data
 Usage Accumulators data
Tariff and Charging Analysis data
Subscriber Life-Cycle data
Dedicated Accounts data
Family and Friends data
USSD and SMS Notification data
Promotion Plan data
HLR blocking data
Community data
Segmentation data

The standard SDP configuration is developed with two identically equipped

servers. The figure contains SCPs to demonstrate the connection to elements
in the SS7 network. Examples of elements connected through the LAN are
also shown.

The Sun Management Center server is a Sun workstation which is also used
for installation and maintenance of the system. For example, it can be used to
run the graphical user interfaces. The main task is however to execute the
alarm monitoring software for hardware alarms.

The SDP cluster is a UNIX based system running on Sun Solaris 9. It is

based on two identically equipped Sun servers. Each server by itself is not
fault tolerant, although many hardware components are redundant.

Instead, the SDP cluster is designed to allow for failures to happen, and the
capacity of the cluster is enough to allow one machine to fail and still be able
to manage all traffic that is generated by the SCPs and other surrounding
network elements.

Each server in an SDP cluster supports up to 2 ISR boards. Each ISR board
supports 64 SS7 LSSL links or 4 SS7 HSSL links. An SDP cluster with one
ISR board per server supports 128 SS7 links.

Additional SS7 signalling capacity can be obtained by using SIGTRAN on a

dedicated Ethernet port or by adding a second ISR board.
2.2.2 Administrative System (MINSAT)

Mobile IN Service Administration Tool (MINSAT) is responsible for all

subscriber administration in Charging System.

MINSAT is the software application that is used by network operators to

manage the Charging System service. The MINSAT client interface consists
primarily of a Java client, which can be run on UNIX or the Windows operating
systems. There is also an Application Programming Interface (API) server that
runs on UNIX and supports a programmatic interface (licensable).

The Java client encompasses the following areas of management:

Customer Care
Administration
Batch Administration
Marketing Statistics
Operation and Maintenance (O and M) Administration

No traffic is handled, but interaction in real-time with other systems for

provisioning and updates, is possible through the external interfaces provided.

At subscriber provisioning and removal, ADMIN may interact both with the AF
and SDP. There is an option to connect external systems, for example HLR
via EMA, to ADMIN for the subscriber administration support. MINSAT
communicates with the other Charging System network elements as follows:
2.2.3 Charging Control Node (CCN)

The CCN logic is able to handle Circuit Switched calls and data for CS1+ as
well as CAPv1, CAPv2 and ERTC accesses.

Handling of SMS over CS1+, CAP v3 (originating SMS) and ERTC is

supported. CCN also handles GPRS over CAPv3.

In addition, CCN contains service logic for the Diameter Service Charging
Application to support Content based services. Other protocols for content
based charging can be supported by connecting the On-line Mediation to
CCN. On-Line Mediation converts a number of different protocols to Diameter
SCAP. For information regarding content based services using Diameter
Service Charging Application.

CCN performs service authorization and rating and returns information used
for Service Aware Charging and Control (SACC 2.0).

For real-time service charging, CCN will convert the incoming messages
(SCAP, CAPv1, CAPv2, CAPv3 or ERTC) to CS1+ messages in order to
enable communication with the SDP. It initiates the interaction with the SDP
where the account using the service is stored in. CCN retrieves data
necessary for Charging System chargeable sessions and events and sends
operations to the SDP for updating of the subscriber account.

CCN support the following functions:

 Interrogation of the SDP
Acting as SCF and SCP for CS1+ access
Acting as gsmSCF for CAPv1, CAPv2 and CAPv3 accesses
Acting as gprsSCF for CAPv3 access
Interrogation of the SDP
Call Control
Call Session Control
Interrogation to FNR for number portability information
Interrogation to HLR for Location information
Access for SMS IN-triggered Charging (CS1+)
Call Control of USSD call-back
Control for Call Related Announcements. The (gsm)SCF function
in CCN controls the announcement equipment indirectly through
SRF.
CDR generation

The CCN is also responsible for the following lists and administration:

Barred Location Numbers

List of MSC-addresses (only for CAPv1)
List of VLR numbers and Location Numbers that belong to the
HPLMN
Number normalization
Mapping of Number Portability Information
and B-number White lists
Configuration data for SDP selection
Configuration data for CDR generation
Configuration data for number conversions (for example country
codes, national/international prefixes)
Configuration data for call control

2.2.4 Interactive Voice Response System (XML-IVR)

The Interactive Voice Response (IVR) is a voice based self-service

application for refill, account balance and life cycle inquiries, language
settings, subscription changes etc.
The IVR provides recorded menu options (voice prompts) to the subscriber.
The subscriber responds by pressing the specified keys on the mobile device
(DTMF signaling).
 Figure: IVR connections

Ericssons VXML IVR Application is based on the VXML (Voice XML)

standard. The application can inter work with any media platform supporting
the standard. Ericsson has verified its VXML IVR Application inter working
with HP OpenCall Media Platform (OCMP), which supports the standard, and
Ericsson.s requirements on a media server.

Application Server
VXML IVR Application

Configuration Callflow Log management SNMP

Management Application
Statistics management

JBoss Web Server Alarm management

HTTP
OCMP Platform OSS

VoiceXML Interpreter
SNMP

Call Control

Signaling
SoftDSP
SIP ISDN ISUP

The subscriber can use the IVR to change and enquire about account
Information. The IVR can also be used for getting in contact with the
 Customer Care. By sending announcements and voice prompts to the
subscriber and receiving Dual Tone Multi Frequency tones (DTMF) in
response, the IVR helps the subscriber in the interaction for account updates
and enquiries about account balance- and expiry dates.

After the Welcome message the subscriber is presented with the main menu:

Balance with the options:

- Main Account Inquiry with Dedicated Account Balance
Inquiry
- Accumulator Inquiry
Value Voucher Inquiry
Transfer to CSO
Language Change
MSISDN Readout
Advertising Announcement
Refill

2.2.5 Account Information and Refill System (AIR)

The AIR system contains logic for refilling subscriber accounts. It performs the
calculations needed for extending expiry dates and adding money to the
subscriber accounts. The AIR system also provides information related to the
subscriber accounts.

The AIR system can handle refills initiated from many different sources both in
the SS7 network and in the IP network. The AIR system is connected to the
IVR(s), the SDP(s), the VS, the AF and to the ADMIN system. It can also be
connected to the OSS for fault management using the TXF alarm adaptation
unit in the OSS.

The AIR system consists of one or several AIR servers. Each AIR server is in
itself an autonomous system consisting of both hardware and software.
Deploying multiple AIR servers provide redundancy, while at the same time
increasing capacity.

No information about the subscribers is stored on any of the AIR servers. Any
AIR server is therefore able to handle requests from any subscriber at any
time. Business data can be synchronized between the AIR servers.

The clients of the AIR system, that is the ADMIN, the IVR(s) and the HLR(s)
may at their own discretion, route communication data to two or more AIR
servers in order to benefit from the capacity and redundancy provided.

Requests to refill prepaid accounts are routed to the AIR system. The AIR
system calculates the refill data and then updates the account in the SDP. For
voucher based refills, the AIR system consults the Voucher Server system.
Requests for obtaining account information such as balances and expiry
dates are also routed to the AIR system, which then obtains the required
information from the account in the SDP.
 It is also possible for the subscriber to refill the account using a specific USSD
service code together with an activation code. The activation code is used for
identification of the unique refill voucher in the VS.

AIR supports the following Unstructured Supplementary Service Data (USSD)

functions:

USSD Voucher Refill

USSD Enquiry

The AIR is also responsible for the following:

Administration of Promotions
Refill configurations
Administration of USSD-communication

This includes administration of text-messages and signalling configuration.

2.2.6 Account Finder (AF)

The AF enables usage of multiple SDPs. It is collocated with AIR.

2.2.7 Voucher Server (VS)

The VS system is a subsystem in Charging System that stores and manages

vouchers. The VS can work as a stand-alone system or it can cooperate with
the AIR server and the SDP to perform a full voucher refill function. The VS
offers generation, storing, and administration of vouchers. Security is obtained
by encrypting the voucher activation number in the database.

When subscribers want to refill their prepaid accounts, a request to do so is

routed to the AIR system. The AIR system requests the VS system to reserve
a voucher for the subscriber. If the voucher is available and has not expired,
the VS system returns voucher data to the AIR system, which then proceeds
to calculate refill data. The AIR system then updates the subscriber's account
in the SDP. If the update of the account was successful the AIR system
requests the VS system to commit the usage of the voucher. The voucher is
now used and cannot be used again. Should the update of the account fail,
the AIR system instead requests the VS system to rollback the reservation of
the voucher. The voucher is now available for usage again.

The VS is responsible for the administration of vouchers with following

administrations:
Voucher Generation
Import of voucher-batches generated by a third-party source
Purging of Vouchers and Voucher history
Batch State Changes
Individual Voucher State Changes
Reporting
Enquiries of Voucher Information

2.3 Associated network elements

Associated network elements that can be integrated with CS30:

 Ericsson Multi Activation (EMA)

Ericsson Multi Activation provides the operators with a uniform

machine-to-machine interface between business system and network
elements that store subscription-related information. It may be used for
service control barring and for ADMIN provisioning. It can be co-located with
small MINSAT.

Multi Mediation Solution (EMM)

Ericsson Multi Mediation, is a flexible interface used for handling of the Call
Detail Records (CDRs) produced by Charging System for further processing
in other network elements. A Multi Mediation solution is necessary for the
processing of Call history. The Call History feature is available when using
MINSAT as administration system.
A Multi Mediation solution is necessary for the feature CDR Processing. The
Multi Mediation Solution filters Charging System CDRs to be handled for
Offline charging, and re-formatted copies of the selected CDRs are sent on a
unified interface to the SDP where charging analysis takes place.
For Real Time Charging, Multi Mediation will convert incoming messages in
Parlay into SCAP-Diameter requests.

Home Location Register (HLR)

All Charging System subscriptions are stored in the Home Location Register
(HLR), just like ordinary postpaid subscriptions. The SDP uses the HLR for
barring of certain services, for example, terminating calls to a Charging
System account.

Mobile Services Switching Centre/Visitor Location
Register
(MSC/VLR)

All circuit switched calls to be charged by Charging System are routed by an

MSC to an SSF or gsmSSF. Circuit Switched Mobile-originating SMSs
handled by Charging System, are routed to the gsmSSF.

Service Switching Function (SSF)

The SSF initiates service execution in the PSL, and receives instructions from
the PSL on how to handle the call. The SSF supervises calls and reports call-
duration to the PSL. The SSF is normally integrated in the (G)MSC/VLR.

Serving GPRS Support Node (SGSN)

 The SGSN handles all packet data services in the mobile network. This
includes mobility management such as intersystem hand over within and
roaming between-mobile networks and logical link management. The SGSN is
responsible for establishment, modification and release of end user PDP
contexts and for handling of packet switched SMS.
It will be integrated in the CGSN.

Gateway GPRS Support Node (GGSN)

The GGSN contacts the Charging System for rating and charging.
The GGSN provides an interface between the SGSN (towards the MSs) and
Packet Data Networks (PDNs), such as the Internet, corporate intranets, and
private data networks. It will be integrated in the CGSN.

2.4 Machine-Machine (M2M) Interfaces

The Machine to Machine interfaces between the network elements in

Charging System are explained below.

ISDN User Part (ISUP)

ISUP is the Signalling System No. 7 (SS7) protocol that provides the
signalling functions required to support basic bearer services. It is used
between MSC and HP-IVR or VXML-IVR. It is also used between (G)MSC
and stand-alone SSP.

CAMEL Application Protocol (CAP)

CAP is an SS7-based protocol used for the communication between

gsmSSF/gprsSSF, gsmSCF and gsmSRF. Charging System supports three
different versions of CAP:

1. CAPv1

Charging System uses CAPv1 together with INAP CS1+ for CS On-line Cost
and Credit Control (CAMEL ph1 based). Originating and forwarded calls in
VPLMN are routed to the HPLMN using CAPv1 after which INAP CS1+ is
used for charging and further control of the call.

There are no announcements provided by CAPv1, but INAP CS1+ provides

the mechanism to play announcements.

The gsmSCF function for CAPv1 in Charging System is provided in HPLMN

by either SCP-T, INS, CCN or a combination of those network elements.

2. CAPv2
Charging System uses CAPv2 for CS On-line Cost and Credit Control
(CAMEL ph2 based). Originating, forwarded and terminating calls are
supported both in HPLMN and VPLMN. Call setup announcements can be
played through an assisting gsmSSF in HPLMN in case the gsmSRF in the
visited MSC/VLR in VPLMN cannot provide the proper announcements. In-
call announcements are not supported by CAPv2 but a tone can be played 30
seconds before call cut-off instead.

The gsmSCF function for CAPv2 in Charging System is provided in HPLMN

by either SCP-T, INS, CCN or a combination of those network elements.

3. CAPv3

Charging System uses CAPv3 for SMS Real-time Charging Based on CAMEL
Ph3 and for GPRS Real-time Charging Based on CAMEL Ph3. Circuit and
packet switched originating SMS as well as GPRS is supported both in
HPLMN and VPLMN.

The gsmSCF function for CAPv3 in Charging System is provided by the CCN
in HPLMN.

Ericsson Real Time Charging Protocol (ERTC)

Charging System uses ERTC for CS and SMS On-line Cost and Credit
Control (Ericsson Proprietary, ERTC/RTCfA). Originating, forwarded and
terminating circuit switched calls and originating and terminating SMS are
supported in HPLMN. Roaming terminating calls are supported if the gMSC is
located in the HPLMN.

The reason to use ERTC is that capacity is gained in the MSC server
compared to usage of CAMEL based On-line charging control services.

Announcements with ERTC are handled the same way as announcements

with CAPv2.

ERTC is based on the Diameter Credit Control but has been adapted to be
able to be sent with TCAP/SS7 as a bearer.

Diameter Service Charging Application Protocol (SCAP)

Diameter Service Charging Application is a vendor specific application that

run as an application on the Diameter base protocol. The Diameter base
protocol is understood and supported by application servers residing in the
service network. The application servers will execute internet application
services and service enablers will be able to provide the application servers
with interfaces and interworking capabilities with Charging System through
CCN.

The Diameter interface can be used to connect to the Online Mediation.

Lightweight Directory Access Protocol (LDAP)

The LDAP interface is used between two SDPs or between SDP and an
external database in order to fetch community data for the non-charged
subscriber. LDAP is used for provisioning and management of PSL and
between EMA and CCN for subscriber provisioning.

Diameter Service Rating Application Protocol (SRAP)

Diameter Service Rating Application is a vendor specific application that run

as an application on the Diameter base protocol. Diameter Service Rating
Application is used between GGSN or SASN and CCN for Service Aware
Charging and Control (SACC).

Mobile Application Part (MAP)

MAP is an SS7-based protocol used for data deliveries between different

network elements. MAP provides the signalling procedures required for
information exchange between entities in the GSM network. To support
CAMEL, MAP version 3 or later is required between:

the VLR and HLR

the GMSC and HLR

Any Time Interrogation (ATI)

ATI is an operation used for queries from CCN and Charging System IN to the
HLR in order to retrieve location information for a specified subscriber.

Unstructured Supplementary Service Data (USSD)

(ETSI) MAP is used for sending and receiving USSD-operations between the
HLR and AIR for Refill and enquiry, and between HLR and SDP for USSD
End-of-Call notifications. The protocol used is based on 3GPP TS 29.002 and
used for both USSD requests initiated by MS as well as USSDs initiated by
network. (ETSI) MAP is also used between HLR and SDP for triggering a
USSD Call back call. Only phase 2 mobiles (or higher) is supported.

Note that the HLR must for mobile initiated USSD (that is for enquiries, refill
and call-back) be able to provide an MSISDN to the Charging System. The
HLR must for network initiated USSD (that is notifications) be able to accept
an MSISDN as the only subscriber identifier.

Alcatel HLR in the Network should support USSD operation.

Ericsson adaptation of MAP

The Ericsson variants of the MAP-signalling protocol, with propriety

extensions, are protocols defined to transfer data for the Ericsson proprietary
services.
Unstructured Supplementary Service Data (USSD)

Ericsson's adaptation of MAP, EMAP, is used for sending and receiving

USSD-operations between the HLR and AIR for Refill and enquiry, and
between HLR and SDP for USSD End-of-Call notifications. The protocols
used are EMAP version 1 and 2. EMAP version 1 can be used for USSD
requests initiated by MS, while EMAP version 2 can be used for MS, as well
as USSDs initiated by network. EMAP is also used between HLR and SDP for
triggering a USSD Call back call.

Mobile Number Portability (MNP)

ATI with Ericsson proprietary extensions is used for queries from PSL,
Charging System IN and CCN to the Mobile Number Portability database
located in FNR.

Intelligent Network Application Protocol (INAP CS1+)

INAP CS1+ is based on ETSI Core INAP CS1, enhanced with ITU-T CS1 and
CS2 functions. Furthermore, Ericsson has added specific functions to create
the Ericsson INAP CS1+ protocol. The INAP protocol is used for the
communication between SCF-SSF, SCP-AIR, and SCP-SDP. INAP CS1+ is
also used between CCN and SDP.

Man-Machine Language (MML)

MML is a language used for communication with exchanges. The command

language for AXE is an application of the ITU-T-MML. There are also some
additional functions, which have not been defined by ITU-T.

MML is, for example, used for the following:

Barring and Unbarring of services through SDP and HLR with

communication over TCP/IP.
A number of activities, for example, installation and removal of subscribers
through MINSAT and HLR or EMA and HLR with communication over TCP/IP
or X.25.
Provisioning and Management of Charging System IN and IN-IVR
Services through SMAS and SCP with communication over TCP/IP or X.25.
Life Cycle notification to external system.

File Transfer Protocol (FTP)

FTP is a protocol in the TCP/IP family used for transferring files between
machines running TCP/IP.

FTP is used for the following:

FTP over TCP/IP is used for transport of CDRs between SCP, PSL, CCN,
SDP, AIR, DWS, the Multi Mediation solution and ADMIN.
 Transport of number lists between the SDP and the Multi Mediation
solution, for batch files on the AIR, SDP, VS and ADMIN as well as for
sending balance threshold notification-files to external entities.

Customer Administrative Interface (CAI)

Ericsson's CAI is an interface between a Customer Administration System

(CAS) and Charging System network elements.

CAI is used for the following:

It makes it possible to send commands through a TCP/IP or X.25

connection.
CAI over TCP/IP is provided in MINSAT for subscriber administration.
The MINSAT API is based on a CAI service model, and allows client
applications to access the MINSAT system in order to insert, modify or delete
data. The MINSAT interface uses a syntax based on CAI. It is not a full
implementation of the CAI interface and it uses functions that are not part of
CAI.
Communication between SDP and EMA in order to access HLR.
Barring and Unbarring of services through SDP-HLR with communication
over TCP/IP.
A number of activities, for example installation and removal of subscribers
through MINSAT-HLR with communication over TCP/IP or X.25.
Provisioning and Management of Charging System IN and IN-IVR (SCP-T)
Services through SMAS-SCP with communication over TCP/IP or X.25.
Provisioning and Management of PSL.
Family and Friends.

Customer Care API (CC-API/CC-ADMIN)

CC API is used on MINSAT. The MINSAT API is implemented as a CAI-

service model and enables client applications to communicate with the
MINSAT system to perform subscriber provisioning and customer care tasks.
The MINSAT API server can be configured as a network service on UNIX.

Administration Communication Interface Protocol (ACIP)

ACIP is based on XML-RPC over HTTP. ACIP is intended as an option to

integrate an external system for subscription administration of Charging
System.

User Communication Integration Protocol (UCIP)

UCIP is based on XML-RPC over HTTP. External refill support and extraction
of account details from Charging System is provided through UCIP.

Voucher Server Integration Protocol - Administrative (VSIP-A)

VSIP-A is an XML over HTTP based protocol, which makes it easy to

integrate with a central integration point within a network. The protocol
supports administrative and refill related services.
 XML/HTTP

XML/HTTP is used in the communication between AIR and both the

administrative system MINSAT and ASCS. It is used between HP-IVR or
VXML-IVR and AIR for refill and enquiries. It is also used for voucher
enquiries between VS and both MINSAT and ASCS, as well as between AIR
and VS for refill.

Remote Procedure Call (RPC)

The RPC protocol is used both by MINSAT and ASCS for administration of
account- and subscriber data, and for user communication through SDP.

Domain Name Service (DNS)

The DNS protocol is used for look-up of SDP-identity and address in the AF.
MINSAT and ASCS uses DNS also to update the AF.

Short Message Peer to Peer (SMPP)

The SMPP protocol is used for the signaling between SDP and SMS-SC in
order to achieve SMS notification.

2.5 Signalling

The transition from TDM based SS7 signalling to IP based signalling is also
occurring within Charging System similar to the core network. In Charging
System 3.0 a number of new IP based protocols are used and the introduction
of new IP based protocols is also planned for future releases.
Figure below provides an overview of the SS7 and IP based interfaces in
Charging System 3.0
2.5.1 HSSL and SIGTRAN

HSSL and SIGTRAN have been introduced in a phased manner to Charging

System. The primary objective is to alleviate the limitations that narrowband
SS7 links (LSSL) give in terms of signaling capacity. With HSSL or SIGTRAN
the operator can fully utilise the node capacities.

Another benefit of HSSL and SIGTRAN compared to traditional LSSL is that

the number of links will be reduced which will lead to less maintenance and
configuration.

Note that the introduction of HSSL or SIGTRAN may require a reconfiguration

of the SS7 network. For instance STP, SGw and signaling relay functions
must be considered, as well as the IP backbone in case of SIGTRAN.

In summary all AXE based nodes, the Mobile-MGw, SGSN and the SDP
supports all three signaling types. HP-IVR supports only LSSL. It should be
noted that the nodes that support more than one signaling type may have
restrictions if and how these can be mixed.

SDP AIR and CCN support HSSL and SIGTRAN in CP6.

3 Offered Charging Solution for TELCO X

3.1 Dimensioning Figures

The Charging System service is used in different ways for different markets,
depending on the charging strategy of the operator. The traffic model aims at
describing the behavior of the Charging System subscribers or technically the
frequency-distribution of Charging System traffic cases.
It is assumed that standard or average traffic model is used in the TELCO X
Network and dimension calculations are performed based on this assumption
3.1.1 Proposed Network Architecture

3.1.2 SDP

The SDP holds the subscriber data (service class, account value, account life
cycle data, subscriber status and so on). When any charged activity is going
to be made in the network, a dialogue to the SDP is necessary. Most requests
from customer care and all user initiated requests through IVR or USSD is
also processed by the SDP.

The SDP load during peak hour depends on many parameters and operator
traffic account model.

The impact on the Charging System from the traffic cases above varies,
depending on the functions that are activated and the traffic mix. The number
of transactions that can be processed by the Charging System thus depends
on the usage.

The capacity of the SDP at the CPU load regulation limit is given using the
default traffic model.

The standard SDP includes two clustered Sun Netra T2000 servers.
 Ericsson Standard SDP (SUN Netra T2000 AC, 8-core, 1.2GHz, 16GB,
2x146GB) can supports approximately 400 call/sec. (1440 K BHCA )

ONE Standard SDP is offered to TELCO X.

3.1.3 CCN

CCN is responsible for call control of circuit switched calls and data, GPRS,
SMS and content based services communications.

The CCN logic is able to handle CS1+ as well as CAPv1 and CAPv2 access
for voice. It initiates interaction with the SDP to retrieve data necessary for
Charging System chargeable sessions and events and sends operations to
the SDP for updating of the subscriber account.

In addition, CCN contains service logic for the Diameter Service Charging
Application to support Content based services. Other protocols for content
based charging can be supported by connecting the On-line Mediation to
CCN. On-Line Mediation converts a number of different protocols to Diameter
SCAP. For information regarding content based services using Diameter
Service Charging Application.

CCN runs on top of TSP/INS NSP5.0 platform. CCN is delivered in a variety

of sizes; MICRO, MINI, MIDI and MAXI. Refer to enclosed CCN Product
Specification for further information.

A Midi NSP 5.0 CCN can handle:

2500K BHCA for CAP v2 Voice,

or 5500K BHCA for diameter Direct Debit session,

or 3850K BHCA for Diameter session without interim session.

Two Midi NSP 5.0 platform CCN will be offered handle all Circuit switch voice,
data, SMS and content traffic.

TWO Midi platforms also provide full network redundancy.

3.1.4 AIR

The AIR node(s) handles all refills and enquiries in the network. The following
traffic cases and features affect the load in AIR:

Voucher and value voucher refill from IVR

Enquiry from IVR

USSD Voucher and Value Voucher Refill

USSD Enquiry
 UCIP traffic

Adjustments

Batch files

Use of Dedicated Accounts

ETSI MAP USSD Refill

ETSI MAP USSD Enquiry

Standard AIR or co-located with AF runs single Netra T2000 1200MHz T1 8

cores with 8 GB memory.

Dimensioning figures are:

An average of 10 DA/subscribers: 130 refills/s with no other traffic or 320

enquiries/s with no other traffic

an average of 5 DA/subscriber: 130 refills/s with no other traffic or 350

enquiries/s with no other traffic

With an average of 0 DA/subscriber: 130 refills/s with no other traffic or 400

enquiries/s with no other traffic

From a capacity point of view it does not matter is the refill or enquiry is
executed via IVR or USSD

Two standards AIR/AF Server are offered to TELCO X, two server provide
redundancy.

3.1.5 VS

The Voucher Server contains the voucher database and handles all voucher
refills in the network.

All voucher refills through customer care or IVR in the network impacts the
Voucher Server. The VS load per subscriber consists of the following traffic
cases:

Voucher refills
Value voucher refills

Standalone VS node as a two T2000 servers cluster with redundant disk

arrays and 4 CPUs per server.

Standard VS capacity is 160 refills/s

Note that this is the dimensioning limit for the disk system.

Maximum number of vouchers: - 320M with 3510 Disk Array

 ONE Co-located VS/AIR is offered.

3.1.6 MINSAT

The following traffic cases and features affect the load on MINSAT:

Customer care activities via GUI

Requests from externally integrated applications via CC API

Data record processing for Account History and Call History

Batch processing (installations, subscriber data changes, deletions)

A medium MINSAT Configuration is offered to TELCO X.

3.1.7 Summary

According to dimensioning calculation following network elements are offered

to TELCO X and this project will include installation, integration and testing of
following network elements:

Node Number SW Level HW types

SDP (cluster) 1 SDP 4.4 T2000

MINSAT 1 MINSAT 5.6 Medium, V440

CCN 2 CCN 5.1 NSP 5.0 Midi

VS 1 VS 2.3 T2000

AIR/AF 2 AIR 2.2 T2000

XML-IVR 1 VXML-IVR 1.2 HP OCMP

3.2 Offered Features

Below table lists the features available on CS3.0 and which ones are offered
for TELCO X.
Basic Features Will be Used
Account Grouping Yes
A/B -number White number list
Yes
Account History Yes
Balance Dependent Tariff Yes
Balance Threshold Notification to External System Yes

Batch Refill Yes

Call History Yes
CS Online Cost and Credit Control (CS1+) Yes
Dedicated Accounts Yes
Enhanced Subscriber Segmentation Yes
Emu Adaptation
Enhanced Voucher Security Yes
Family and Friends Yes
Personalized Service Offering
Yes
Market Segmentation Yes
Multi user account Yes
Number Plan Change
Periodic Service Fee Deduction Yes
Pre-Activated Accounts Yes
Realtime Lifecycle Reporting Yes
Recharge Promotions Yes
Screening Yes
Snap Shot Report Tool Yes
Statistics Data History (MINSAT) Yes
Subscriber Administration ADM Yes
Tariff Management Application Yes
Toll-free Numbers Yes
Value Voucher Yes
Voucher Generation Yes

Optional Features Will be Used

Bonus on Incoming Calls Yes
 CAMEL Ph1
CAMEL Ph2 Yes
CDR processing Yes
Community Charging Yes
Account Admin Communication Integration Protoco
Yes
Enhanced service fee deduction
Yes
External Alarm Handling Yes
GPRS Realtime Charging based on CAMEL Ph3 Yes
User Communication Integration Protocol Yes
Voice XML IVR Yes
Mobile Number Portability, ATI based Yes
Negative Balance Yes
Open Charging Interface (Diameter)
Yes
MSC Charging i/f on CCN
Yes
Premium Refill Yes
Rating for Flexible Bearer Charging Yes
SMS Realtime Charging based on CAMEL Ph3 Yes
SMS Realtime Charging based on CS1+ Yes
Tariff and Bonus Based on Accumulated Usage
(TBAU/BBAU) Yes
USSD Balance Inquiry, Notification Yes
Mnsat Customer Care API Yes
Self Service Charging Yes
USSD Callback Yes
MVNO Support Yes
USSD refill Yes

Descriptions of offered feature can be found in following table:

Feature Service Description

Type

USSD Balance Increase With Notifications, information on upcoming

Inquiry, Notifications usage and awarded bonuses can be sent to a
& Refill subscriber after a subscriber has performed
a transaction. In this way you can increase
the subscriber usage. USSD end of event
notifications can be tailored for different
subscriber segments, different services and
individual subscribers, hence adding more
user value as users only receive
notifications that are relevant to them.
USSD Call Back Roaming When using USSD Callback, the Charging
System subscriber dials a USSD service
code followed by the B-number, for example
*123*81234567#, where *123* is the
service code for roaming calls.
GPRS Realtime Roaming Charging may be based on both location
Charging (for roaming subscribers) and the dialed
destination. CAMEL Ph 3 supports unique
toll-free and allowed number lists, unique
announcements for roaming subscribers,
barring of roaming areas, charging of
forwarding and terminating leg.

SMS-MO Realtime Roaming SMS-MO Realtime Charging based on

Charging, CAP3 CAMEL Ph 3 adds roaming capabilities to
CS MO SMS. Charging can be based on
SMS-C Address or Called Party Number.
Allowed and Barred Lists over SMS-Cs
prevent fraud. The feature works in a multi
vendor network but Ericsson MSC/VLR
support in the network is required.

Mobile Number Loyalty Enables operators to distinguish between

Portability on net and off net calls and allows
subscribers to maintain their MSISDN when
switching network operators

Negative Balance Loyalty Negative Balance

Enables subscribers to be allowed a credit
on the account
Debt Warning announcement
Defined per Service Class
Configurable Grace Period

Balance Dependent Tariff

Enable the operator to apply different tariffs
depending on the account balance. The
account balance at call set-up determines
the tariff for the whole call.
Configurable call set-up announcement

Bonus on Incoming Increase The feature is implemented as a negative

Calls Usage tariff in the tariff tree, allowing the system to
credit the subscriber account every time a
call has been received.
Community Loyalty Cheaper/different tariff within the same
Charging community
Works for both pre-paid and post-paid
subscribers
Works for all services (Circuit switched
voice, SMS, MMS, GPRS)
Special notification (by means of USSD
End-of-Call) when calling inside community
Independent of Service Class
Support for Service Fee Deduction
Handles up to 9 million subscribers per
community
Handles up to 10M communities
Selection of Dedicated Account depending
on community
Multiple Communities per account (up to 3)
Tool to increase:
customer loyalty and reduce churn
increase on-net usage
increase usage of content, e.g. football goal
streaming service to members of a football
club community.
Improved segmentation possibilities. Tool to
reach low-spending subscriber segments,
e.g. students

Open Charging Content Many different types of content-based

Interface based on services can be charged for, for example:
Diameter Goal services
Weather services
Ticket reservations
Ring-tone download
Comic strips

User Communication System The protocol can be used for the following:
IP Accumulator inquiry
Balance inquiry (main and dedicated
accounts)
Refill
Standard Voucher Refill
Value Voucher Inquiry
Value Voucher Refill
Positive Adjustment (Main + dedicated
accounts) including setting of supervision
expiry date and Service Fee expiry date

Admin System ACIP is an open interface to Charging

Communication IP system for administrative functions.
This interface can be used for admin
functionalities like create / modify
subscription so on..
MVNO System Mobile Virtual Network Operator Support.
Can have different system views and
access for different Service Providers.
Premium Refill Increase Allows the subscriber to simultaneously
Usage change the Service Class and refill the
account.
Service Class change can be performed by
Customer Care, through a
premium refill, through a value voucher refill
or through UCIP

Enhanced Service Increase For a subscriber who has subscription for

Fee Deduction Usage push out message and family & friends
discount, operator can charge a monthly
service fee for message and quarterly
service fee for family & friends.
To make new service launch more
attractive it is possible to suppress first
service fee deduction. Subscriber pays a
weekly fee to have access to Mobile TV
service, first week fee is free of charge as
promotion for the new service.
An operator launches a summer campaign
with discounted roaming rate. For
subscribers who sign up for this campaign a
service fee will be deducted monthly within
3 months period, say from July 1st until
September 30th.

Minsat Customer System The primary purpose of the API is to allow

Care API operators to integrate legacy customer care
application systems with Charging System.
It may also be used by bespoke third party
applications, which need access to the
functions made available through the API.
Self Service Increase Operator has the possibility to charge a
Charging Usage subscriber when he is performing self
services like Family and Friends
administration, subscription change or
balance
inquiry. Charge different rates for different
actions. Additional IVR call flow config will
be required.
CS On-line cost and System Main Charging System feature enables the
Credit Control operators to perform real-time charging with
(Ericsson CS1+) session supervision for all call cases.
Batch Refill System Refill subscriber accounts using a batch file,
allows operator make bulk refill for the
subscribers for several reasons.
Voucher Security System Voucher security feature make voucher
activation codes encrypted. This allows the
operator to keep the voucher data in
secure.
Number Plan Change System Number Plan Change offers an efficient way
to change number series, hence simplifying
administration of MSISDN number series.
The batch jobs can be executed during low
traffic periods without any disturbances in
the service. An operator decides to change
the number series starting with 555 to
starting with 2555
Pre-Activated System The Pre-activated Accounts feature allows
Accounts new subscribers to activate their accounts
without having to make a specific activate
account call to the IVR; the account is
activated on the first session initiated by the
new subscriber.
Depending on the operators system
configuration, various subscriber accesses
to a new account can trigger activation of
the account: originating calls, including toll
free calls, calls to the IVR or USSD access.
Snap-Shot Report Reports The Snap-Shot Report Tool provides
Tool operators with an instant view of selected
information in the account database in the
SDP. The feature is delivered with a number
of predefined reports, which simplifies
generating of subscriber and account
statistics. It is also possible to add
customized reports, for specific purposes.
The reports support business related
decisions and the report format enables the
data to be smoothly imported into external
tools like spreadsheet applications.
Examples
An administrator wants to check the total
debt among subscribers who are allowed
Negative Balance and chooses the
predefined report for total negative balance.

A/B-number White System The B-Number White list contains the

List numbers to taxi-companies to allow
subscribers to call a taxi also when
technical problems prevents access to the
SDP.
One operator allows calls to fixed phones
but not to mobile phones.
One operator uses the Mobile Number
Portability support to allow on net calls, but
not off-net calls.
Screening & Toll- System The Screening & Toll-Free Numbers feature
Free Numbers allows the operator to bar specific numbers
or number series and to define numbers
available free of charge in a controlled way.
It is possible to use separate lists for
subscribers in different Service Classes that
is to configure the call limitations differently
for different target groups.
Examples
The number series 12 is barred in the
barring list. If 123 is defined in the allowing
list, all numbers in the number series 12 are
barred except for those in the number
series 123.
Tariff Management System The Tariff Management Application
Application provides advanced rating capabilities and
offers sophisticated market segmentation
possibilities as well as a secure tariff
management.
Tariff structures are edited and tested offline
using a user-friendly GUI. Tariffs are built in
a tree-structure with nodes, branches and
leaves. The nodes hold the conditions for
determining which branch to follow. The
branch is used when specific conditions
apply, for example charging based on
location, where the base station ID is used
as a branching condition.
Voucher Generation System The Voucher Generation feature enables
operators to employ a personalized and
secure voucher administration system. It
guarantees uniqueness of the generated
voucher data as serial numbers and
activation codes are unique within the
Voucher Server.
Voucher administration is performed in a
user-friendly GUI.
Family and Friends Loyalty Family and Friends (FaF) enables discount
rates for favorite numbers and number
series, defined for both originating and
terminating calls and SMS. FaF can be
used for both single and multi-user
accounts. Multi-user accounts may contain
both a general and individual FaF lists.
These lists are checked with priority hence
ensuring that the numbers on the lists are
rated correctly.
Market Segmentation System The Service Class concept is an advanced
market segmentation tool, a means to offer
customized customer agreements to
different subscriber groups.
The Service Class includes all available
parameters for a customer agreement;
specifies included services, life cycle
properties, tariff plan, currency, language
etc.

Multi-User Account Increase Attract families, small enterprises and other

Usage types of small groups with Multi User
Accounts.
Rating and deduction from the common
account is performed in parallel. All
subscribers has authority to refill the
account and to perform inquiries towards
the account, but only one Master
Subscriber has authority to add and remove
sub-subscribers. If the Master Subscriber is
removed, all sub-subscribers are removed.
Dedicated Accounts Increase Dedicated Accounts are powerful tools in
Usage the promotion program as they enable
operators to promote both subscriber-
behavior for example refill, and usage of
specific services, for example GPRS, MMS,
SMS or content-based services like a news
subscription. Campaigns
An operator wants to promote MMS usage
during Christmas and offers 100 MMS for a
bargain price. Subscribers sign up for the
Christmas Campaign by refilling their
accounts using a specific voucher with the
value 50 plus a promotion of 10 percent.
The result of the refill (value 55) is placed
on a Dedicated Account for MMS with an
expiry date after the Christmas holidays
(January 8). After this date the Dedicated
Account is deleted. Stimulate Refill and
Usage
An operator uses Refill Based Promotions
to promote refill among subscribers in the
Student Service Class and at the same time
stimulate usage. On each refill, Student
subscribers are granted a 15 percent bonus
on the value of the voucher. The bonus is
placed on a Dedicated Account for voice
and SMS. The bonus is hence restricted to
be used for voice calls or SMS. Promote
New Services
An operator has introduced an MMS Goal
Service, and wants to promote it towards
subscribers with GPRS and MMS access.
The operator creates a Dedicated Account
for the Goal Service in all Service Classes
with GPRS and MMS access.
The operator also dedicates an accumulator
for MMS and introduces a Bonus based on
Accumulated Usage for MMS: After 5 sent
MMS, subscribers receives a bonus of 1
which is placed on the Dedicated Account
for the Goal Service.
The operator also introduces a Refill Based
Promotion of 5 percent and this bonus is
also placed on the Dedicated Account for
the Goal Service.
Funds can be loaded onto a Dedicated
Account through:
Voucher Refill using the IVR or USSD
Manual adjustments from the admin
system
Batch Refill from AIR
Automatic adjustment when the user is
granted a bonus (for example Recharge
Promotions)
Refill Promotions Increase Refill Promotions is beneficial for both the
Usage subscriber and the operator. It is an
important element in the operators
customer loyalty strategy.
As Refill Promotions can be awarded in real
time it is possible to immediately notify the
subscriber about the reward, hence
increasing satisfaction.
Examples
The following are examples of promotion
plans for Refill Promotions:
Promotion Plan 1: 30 refills of any value
during one calendar year extend the service
supervision period with one month. If the
subscriber performs 90 refills of any value
during the same year, the subscriber is
reallocated to Promotion Plan 5.
Promotion Plan 5: 15 refills during one
calendar year extend the service
supervision expiry date with one month.
Promotion Plan 2: Refills with an amount
exceeding 1.000 monetary units during
January awards the subscriber with extra
100 monetary units.
Promotion Plan 3: Refills with an amount
exceeding 100 monetary units on March
17th year XXXX, extends the service
supervision expiry date with two months,
the Service Fee Period with 20% and an
extra 20% of the refill value is added to the
account.
Promotion Plan 4: Refill the account at
least 15 times during the second half of
year XXXX to receive extra 50 monetary
units.
Realtime Lifecycle System The Realtime Lifecycle Reporting feature
Reporting enables improved handling of subscribers
and accounts, by keeping administrative
systems updated on the account lifecycle
status. The feature can also be
implemented to trigger various actions, for
example to activate a service after a
Service Class change.
Example
Subscriber A belongs to the Silver Service
Class, which is a base subscription offering
voice calls, SMS and voicemail services. A
now wants to use GPRS and MMS
Services. A uses a Value Voucher to
permanently switch Service Classes to the
Gold Service Class, which includes the
desired services.
When the Service Class change has been
performed the SDP issues a notification to
Ericsson Multi Activation, which activates
the GPRS and MMS services for the
subscriber.
Service Fee Increase Service fees are instruments to help
Deduction Usage operators to fast launch new services with
secured charging.
Service fees can be used as a
segmentation tool for packages with
different services and tariffs.
The automatic deduction is network
efficient as it can be made during low traffic
periods.
If the account balance does not cover the
service fee, the subscriber can immediately
be barred from either the premium service
or all services.
The interval between the deductions is
configurable by the operator and hence it
can be tailored to best fit each offered
service.
Examples
Mobile Terminating SMS is a typical way
to use service fees: Subscribers receives
for example daily stock exchange
information, soccer results etc. The
operator charges a service fee in advance
and the fee is deducted from the
subscribers account for example each
month.
A subscriber has access to a service with
ring tones for download. Up to five
downloads are free every week and the
user pays a service fee to use this service.
The service fee is deducted from the
account in advance every month.
A high volume subscriber is connected to
a service which give the subscriber lower
tariffs at daytime weekdays. The service fee
is deducted from the account in advance
every week.
An operator uses the Negative Balance
feature. Accounts allowing negative balance
are charged with a monthly service fee.
Value Voucher Increase The Value Voucher feature provides a user-
Usage friendly way of changing the content of the
subscription, for example get access to
supplementary services or lower tariffs.
Value Voucher lowers load on Customer
Care, as subscribers are able to change
their subscriptions by a simple self-
provision action using the IVR or a USSD
service.
Value Vouchers are distributed the same
way and through the same channels as any
other voucher.
Examples
Subscriber A buys a Value Voucher to get
a lower roaming tariff effective during his
two week vacation abroad. This Value
Voucher performs a temporary Service
Class change; after the predefined period,
the subscriber returns to the permanent
Service Class.
 Subscriber B buys a Value Voucher to get
access to an SMS Goal Service offered by
the operator during the Soccer World
Championship. This Value Voucher
performs a temporary Service Class change
to a premium Service Class. After the
championship the subscriber returns to the
permanent Service Class.
Subscriber C buys a Value Voucher to
permanently switch to a Service Class
allowing Negative Balance on the account.

Balance Dependent Increase Balance Dependent Tariffs enables the

Tariffs Usage operator do define multiple tariffs based on
multiple account balance levels, including
negative balance.Balance Dependent Tariffs
increases the rating flexibility. The feature
can be used to stimulate refill, through a
lower rate at high account balance and a
higher rate at negative account balance.
Example
The tariff is higher when there is balance is
negative on the account and lower when
the account balance is more than $30.

Balance Threshold System Balance notifications at specified thresholds

Notification to enable extended user communication and
External System services.
Depending on implementation, this feature
can for example be used to trigger an
automatic refill, to send a balance
notification over SMS to the subscriber or to
block external services. In GPRS
environments a low balance notification
can prevent a download to be started and
then to be cut off due to an empty account.
The thresholds used in Balance Threshold
Notification to External System are fully
configurable by the operator.
Examples
An operator has implemented a bank
interface and uses a low balance threshold
to trigger an automatic refill for customer
segments, which uses this function.
Another operator uses the feature to send
low balance notifications over SMS to
subscribers.
A third operator uses Balance Threshold
Notification to notify external service
providers when an account runs low to
enable the partner to bar the subscription
until the user refills the account.
 Account Grouping System Account Grouping enables selected
subscribers from a single Service Class or
from
several Service Classes to be grouped
together in an Account Group. Grouping
can
be based on for example department in a
company.
The account group id is written to DRs,
which enables a post-processing system to
filter out the specific account group for
reporting purposes or to create hierarchic
account structures.
Examples
An operator uses Account Grouping to
segment their enterprise customers. The
employees at the enterprises belong to
different Service Classes, but the operator
wants to be able to report on department
level. The parameters are written to the DR,
which is sent to the post-processing
system.
It is now possible for the operator to
generate reports on department level in the
company.
Personalized Service Increase The Personalized Service Offerings feature
Offering Usage enhances the already powerful Service
Class concept and enables even more
flexible market segmentation. The original
Service Class concept held all service and
subscriber related parameters in the
Service Class. This has been an advanced
method to group services and tie the
services to subscribers in a flexible way.
The increased possibilities to offer new
value adding services to the subscribers
has however led to a continuously
increasing number of Service Classes, to
cover various combination of services.
The feature also improves rating and USSD
message flexibility, as rating and type of
USSD message can be differentiated for
different subscribers.
New campaigns can be implemented faster
and easier as the subscriber parameter can
be used to find for example subscribers
from any Service Class who has activated
MMS services. It is also easier to handle
several offerings and campaigns at the
same time, which increases the
segmentation possibilities.
The parameter can be used to identify post-
paid and prepaid subscribers in the same
Service Class

3.3 Services
3.3.1 Airtime Transfer
The Airtime Transfer Service will be implemented during launch
 Charging System 3 will only be responsible for validating and updating
subscribers account. Every other function remains the responsibility of
TELCO X
TELCO X needs to develop an external application using UCIP
interface to interface with the AIR server. Details of UCIP can be found
in ALEX documentation. Reference: Airs programmer guide- UCIP.

3.3.2 SACC (Service Aware Charging Control) 3.0

SACC 3.0 will be configured in a number of ways depending on TELCO X

needs and legacy requirements.

Configurations

GGSN R4 handles the inspection and classification of the data flows passing
the GPRS network. The GGSN R4 is the enforcement point of the policies
applied for both charging and access control. GGSN R4 Implements the
Policy and Charging Enforcement Function (PCEF)

Online Mediation 5 handles charging mediation in real time towards an

external charging system (It also offers rating functionality as well as active
balance management in order to complement the functionality offered by the
external online charging system.)

Charging system will be used for policy, rating and charging

NOTE: When Ericsson Charging System 4.0 becomes available it will support
the Ericsson Gy+ interface and hence it will be possible to connect without
using the online mediation component of Ericsson Multi Mediation 5.
 Figure 1 SACC 3.0 Diagram

3.4 Business Processes

3.4.1 Subscriber Provisioning

This chapter describes the subscriber provisioning process to follow in CS3.0

solution.

In Ericsson CS30 solution, if there is more than one SDP on the network, pre-
provisioning of the AF should be performed. The function of AF is to map
MSISDN to SDP for IP based traffic like refill and balance inquiry in CS3.0.

The whole provisioning process is initiated from MINSAT node. See below the
description of the flow.

1. Create Batch provisioning files.

Batch provisioning files can be produced on MINSAT as follows:

a. Generate AF batch provisioning file (only applicable when more

than one SDP is in place).

This can be done using the GUI screen or the command line. From this point
onwards the subscribers are assigned to an SDP. The following parameters
are passed:
Output file name
Start MSISDN of range
Range (Number of subscriptions)
End MSISDN
 SDP ID

b. Generate Subscriber batch provisioning file.

This can be done from the GUI screen or the command line. The following
parameters are passed:
Output file name
Number of master records
Start IMSI
Start SIM
Start MSISDN
Business Plan
Language
Block Status
Promotion Plan data (optional)
SDP
Other optional fields

Find below subscriber provisioning file format specification:

Field Instruction
MSISDN number No more than 28 digits.
Master number No more than 28 digits. Optional.
IMSI number No more than 28 digits.
SIM number No more than 28 digits.
PUK1 No more than 28 digits. Optional.
PUK2 No more than 28 digits. Optional.
Plan ID No more than 4 characters.
SDP No more than 4 characters. Optional.
Language No more than 1 digit. (0-5). Optional.
Promotion Plan No more than 4 characters. Optional.
Promotion Start Date No more than 8 digits. YYYYMMDD.
Optional.
Promotion End Date No more than 8 digits. YYYYMMDD.
Optional.
Temporary Blocking Status SET | CLEAR.

Community Group ID No more than 4 characters. Optional.

Service Offering Plan ID No more than 4 characters. Optional.
Account Group ID No more than 10 digits. Optional.
USSD EOCN Code No more than 2 digits. Valid values 1-99.
Optional
Organisation ID No more than 10 digits. Optional.
 c. Provision on AF(only applicable when more than one SDP is in
place)

The batch previously generated is processed either using the GUI screen or
the command line interface. The subscribers are installed in the AF node.

d. Provisioning of subscribers

The batch previously generated is processed either using the GUI screen or
the command line interface. The subscribers are loaded in the Minsat, HLR
and SDP.

Note: Since TELCO X will use Alcatel HLR in the Network, EMA (Ericsson
Multi Activation) needs to be used in complete User Provisioning solution.
EMA has an interface to Alcatel HLR, So that through EMA, it is possible to
send provisioning command to the HLR from MINSAT.

When EMA is in place, the subscribers will be loaded on the HLR via EMA
using the MINSATSV command. Also, barring of subscribers on the HLR for
outgoing and incoming calls will be initiated by the SDP towards the HLR via
EMA, according to the changes in the lifecycle.

Alternatively, a Customer Admin System (CAS) needs to be developed to

address all provisioning needs. Open Customer Care API (CC-API) can be
used in CAS system development.

Manual installation of individual subscribers can be performed via MINSAT. In

this case there is no batch processing. The data is filled in on the MINSAT
GUI screen and executed directly. However, if used, the AF should have been
previously provisioned.

Figure 2 Interfaces for provisioning without EMA and AF

Figure 3 Interfaces for provisioning with EMA and AF
3.4.2 Postpaid to Prepaid process and visa versa

Figure 4 Postpaid to prepaid flow.

 Figure 5 Prepaid to postpaid migration flow

3.4.3 Forced Disconnection

The following shows the forced disconnections at TELCO X and the figure
below illustrates the flow for forced disconnections for subscribers in CS 3.0.
 In addition to this flow, HLR profiles should also be changed.

Start

Type of
Life Cycle Disconnection Pre to Post Conversion
Disconnection

If Subscriber is
In this case, TELCO X
expired and
will have to
marked for
prepare a file and
Disconnection,
put it in the
MINSAT will
specified directory
delete MSISDN
for which they
from MINSAT and
want to delete in
SDP through mbd
MINSAT.
batch process

MSD utility will

process the
prepared file.

MSD process will

delete the
MSISDN from
MINSAT and SDP.

Response file will

be generated with
the filename with a
~ sign.

End

3.4.4 Voucher Provisioning

This chapter describes the voucher provisioning process to follow in CS3.0

solution.

In CS3.0 Voucher Server offers generation and loading of new vouchers using
batch files from VS GUI. The process will be:

1. Vouchers Batch file generation

2. Vouchers Batch file loading in Unavailable status

3. Send file to manufacturer

 4. Change vouchers status to Available once the physical vouchers are
ready to sell.

Only impact in provisioning process is the format of the batch file generated if
VS is used for such generation. Voucher manufacturer should be able to
extract required information from new file format.

All relevant fields required to create the voucher are included in CS3.0 file
format: group-id, SN, PIN, value, Expiration date, currency and language.

Not included fields: Operation, creation date, bonus, validity extension.

See Protocol Message Specification - Voucher Batch File, in CPI library for
further information on new format.

Bonus and validity extension is not included in the voucher, but is part of the
system configuration on AIR. Both values will be decided upon usage,
depending on AIR configuration.

PIN code becomes encrypted when loading the vouchers into VS database,
but in CS30 VS, "Blowfish" encryption algorithm will be used.

In case there is need to access the PIN code (for instance, if a voucher gets
damaged and the complete PIN code cannot be read), PIN code is still
available in voucher generation files in VS.

3.4.5 Voucher creation, loading and status change

CS 3.0 Proposed Process

1. A Voucher Administrator uses the Voucher Server web-interface secured

via username and PIN, allowing access to Voucher Pin generation feature on
the Voucher Server.

2. The Voucher Generation feature on the Voucher Server generates a DAT

file with a full 14 digit random PIN.

3. The DAT file is DES encrypted.

4. The DES encrypted file is stored on the Voucher Server file system for
loading by a Voucher Server Operator whom can load the file on the Ericsson
Voucher Server.

5. The Voucher Server Operator loads the file onto the Ericsson Voucher
Server.

6. Once the DAT file is loaded, the system generates a LOADED file, which is
still DES encrypted and a RPT file showing the status of the Vouchers i.e.
Success or Failure of the vouchers requested to have been loaded.

7. The DES encrypted LOADED files is PGP encrypted for safe

transportation.

8. The PGP encrypted LOADED file, which is still DES encrypted is securely
emailed or transported to the distributor or Voucher printer.
 9. The trusted distributor and Voucher printer are able to decrypt, PGP using
the public key, the LOADED file; which still requires the DES key for
decryption of the actual data.

Please see the diagram below.

3.4.6 Voucher Loading

The file with created vouchers is stored in the var/opt/vs/ftp/batchfiles/voucher
directory in the VS. Uploading of Vouchers into Voucher Server system is GUI
based. Using the VS front-end application, voucher files can be uploaded with
a Batch ID. The batch ID will be used as a unique identifier of each individual
file. Response file will be generated and has the status of each batch file
process.
 Start

Voucher will be
generated outside
of E /// VS system

By using the front-

end GUI, the
voucher batch file .
will be uploaded
and a response file
will generated.

End

3.4.6.1 Voucher Batch Input File

The Voucher Batch Input file contains two parts - a header part for data that is
common to all voucher entries and a contents part, where voucher entries are
specified.

Header Part

Element Type Mandatory

total_number_of_vouchers Numeric M

activation_code_length Numeric O

currency Alphanumeric O
Record Part

Element Type Mandatory

activation_code Numeric M

serial_number Alphanumeric M

value Numeric M

voucher_group Alphanumeric M

expiry_date Date M

agent Alphanumeric O

extension_text_1 String O

extension_text_2 String O

extension_text_3 String O
3.4.6.2 Voucher Batch Report File
The Voucher Batch Report File reports the outcome of the voucher
batch file after attempting to load the vouchers. It consists of a content
part detailing the voucher for which loading was unsuccessful and a
trailer record for the overall result of the load.

Report Part
This record can either exist for the entire file if the file failed to be
validated due to format errors or per rejected records if the file format is
acceptable but execution for individual records causes errors.

Element Type Mandatory

error_code Numeric M

serial_number Alphanumeric M

Trailer Part

Element Type Mandatory

processed_records Numeric M

batch_status Alphanumeric M

batch_error_code Numeric O
3.4.7 Voucher State change

3.4.7.1 CS3 Voucher State and Lifecycle

A user can initiate a state change job in the Voucher Server. This job
will change all vouchers in either a serial number range or a batch to a
specified state.

A voucher state change report file contains the result of a state change
job.

A voucher state change report file must always consist of one header
and one trailer record. For every voucher that the state was not
changed in the selection there will be one voucher state change record.

Voucher state change report files are named as follows:

STATECHANGE_YYYYMMDDThhmmss_S.RPT

where YYYYMMDDThhmmss corresponds to the date and time the file

was generated, and S is a sequence number to make sure that two
files do not have the same name. If there will be more than 10 state
change jobs during one second there will be two digits of sequence
number.

Figure below illustrates possible state transitions for a voucher.

3.4.8 Subscriber LifeCycle

This chapter describes the subscriber lifecycle that is used in CS3.0.

The Lifecycle service scenarios of a Charging System account depends on
the settings for the following account data:

Account Value
Service Fee Period
Service Removal Period
Supervision Period
Credit Clearance Period

See below the description of the periods that can be configured related to the
Subscriber Lifecycle:

Service Fee Period

The Service Fee period is the time period for which a service is
granted to the subscriber. When the service fee period expires, all
traffic services are blocked, even if there is credit left on the account.

The service fee period is set at account activation and can be

combined with an account refill, but it can also be handled separately.
The service fee can also be deducted in advance, automatically
prolonging the service fee period. When the service fee period has
expired, the service state of the account can be changed. Originating
or terminating services, or both, can also be barred in the HLR.

Service Removal Period

When the Service Fee Period expires, the account is set for Service
Removal. If no service fee is placed within this grace period, the
account will be removed from the operator network.

If a new service fee refill is made while the account is set for service
removal it will automatically be reactivated.

Supervision Period

The supervision period is the time period during which a service is

available to the subscriber before a refill has to be made. The
Supervision period is restarted at each refill.

When the supervision period has expired, the service state of the
account can be changed. Originating or terminating services, or both,
can also be barred in the HLR.

Credit Clearance Period

When the supervision period has expired, the account is set for credit
clearance. When the credit clearance period has expired, the account
balance will, if positive, be set to zero. However, debts will not be
cleared.

If a refill is made while the account is in credit clearance, the account

will automatically be re-activated.

Find below diagram describing lifecycle for CS3.0 subscriptions in TELCO X:

Ericsson CS3.0 solution handles 5 states for subscribers lifecycle:

Installed: the subscriber is created on the system; the account is pre-

activated and can make or receive voice call and SMS. The account will
be activated and Supervision Period and Service Fee Period get an initial
value upon any of the following events:
First originating IN Service event triggered: originating voice call,
SMS or MMS.
Account Refill or Standard Voucher refill through IVR, USSD,
Batch or Customer Care.
First call to the IVR menu
First USSD enquiry
Account adjustment from Customer care with expiry dates update
Temporary Blocked: An account can be temporary blocked by the
system or by Customer Care. This implies that the account is temporarily
barred and cannot be accessed by the subscriber. No incoming or
outgoing services are possible. Refill of the account is not possible. This
status can be reached after the Removal Period is ended or by manual
operation from MINSAT.
Active: subscriber is able to access any available service (outgoing or
incoming voice calls and SMS, data services,etc..). The only limitation for
access to any service is the credit available in the account.
Passive: Subscriber is able to access not charged services: incoming
calls, SMS or MMS, but is not able to access charged services: originating
calls, SMS or MMS. Only free services are available (this includes IVR for
refill). Subscription changes to this state when Supervision Period ends.
After Credit Clearance Period ends, the account is cleared.
No Service: Subscriber is not able to receive calls, SMS or MMS, neither
is able to originate calls, SMS or MMS. Only free services are available
(including IVR for refill). Subscriber comes into this status after the Service
Fee Period expires. After the Removal Period expires, subscriber is
automatically deleted from CS3.0 solution.
 NOTE: for any of the previous statuses, it is possible that the account balance
is in the minimum limit. If this is the case access to any charged service is
denied.

3.5 Account Structures in Charging system

A Charging System account can have one or several subscribers associated

to it. A subscriber is someone who uses Charging System accounts to pay for
services. The subscriber can be either the owner of an account, the master
subscriber, or a subordinate user of the account. See Figure below.

The identity of the subscriber in Charging System is the national (significant)

mobile number which is derived from the MSISDN number.

It is the master subscriber who controls which subordinate subscribers are

allowed to use the account. Procedures for authentication of the master
subscriber at the customer care center have to be established by the network
operator.

A subordinate subscriber is allowed to use the monetary value of the account

to its full extent, together with other subordinate subscribers and the master
subscriber.

All subscribers connected to an account are allowed to refill the account.

The procedure for provisioning and disconnection of a subscriber is described

in Overall Guide Subscriber Provisioning, in CPI.
An account consists of a master account, and optionally, one or more
subordinated accounts.

Master Account

All accounts have a master account this is where the subscriber's account
balance is stored. The master account balance on a Charging System
account corresponds to a monetary value.

Dedicated Accounts

The dedicated accounts are activated in Service Class data for all accounts in
that Service Class and initiated/created by refill or adjustment.

Dedicated accounts are associated with a master account. A master

subscriber can have up to 10 different dedicated accounts for different types
of activities, for example, one for voice calls, SMS or GPRS. A configurable
list will decide which dedicated account to use if there are multiple dedicated
accounts.

The main account state must be in active service in order to be able to access
the value of the dedicated account.

If, for example, a dedicated account exists for SMS, and monetary units are
allocated to it, Charging System will primarily use this dedicated account
when charging for SMS.

When a dedicated account has been emptied, there are two possible ways to
handle charging:

The main account is used for the remainder of the charged event.
The service is interrupted

The behavior in this case is configurable in the Service Class.

Each dedicated account can either have an expiry date or be set in state
active until further notice. If an expiry date is defined for a dedicated account,
the account is only accessible if the session begins before this expiry date. A
general setting (service options) defines how expiry dates are interpreted in
the database. It can be set to allow usage of a service on the expiry date (the
service expires the day after) or it can be set to indicate the day when the
service expire.

When expiry dates are used and when, for example, a promotion is activated
towards the dedicated account, the new expiry date is verified against the
already stored one. The expiry date with the latest date will be used.

It is possible to configure whether the Dedicated Account shall be cleared at

expiry date or not. In case clearing is not done, the amount present at expiry
date will be available in case a new expiry date is set. The cleared amount is
reported in a Data Record (DR).

Usage Accumulators
 The usage accumulators are used for the function Bonus Based on
Accumulated Usage. The operator has the possibility to define five (5) usage
accumulators for different activity types per subscriber account. A usage
accumulator consists of a counter and a time stamp indicating when the
usage accumulator will next be reset to the initial value. The time between
resets is defined in the Service Class data. It is possible to both increase and
decrease usage accumulators.

The usage accumulator is also used for the function Tariffs Based on
Accumulated Usage.

3.5.1 Account Refill

A refill to a Charging System account can be done through Account Refill,

through Customer Care, through a Batch, through Standard Voucher Refill, or
Value Voucher Refill as illustrated in below:

IVR USSD Customer Care CC- API in UCIP

Minsat

Account Refill x x x

Standard x X X x x
Voucher Refill

Value Voucher x X X x x
Refill

The voucher is considered as cash and the value lies with the hidden
information. All voucher information is stored on the VS.

A refill with a Value Voucher will initiate a Service Class change.

A refill with a Standard voucher will add monetary units to an account, and
extend the service fee- and supervision periods.

3.6 End-User communication

This chapter describes the different methods for communication to the end
user in CS3.0 solution.

3.6.1 Account Refill

IVR

IVR refill function will be available in CS3.0 by dialing the IVR number and
indicating the PIN code for a voucher.

USSD
 USSD refill will be available in CS3.0 by sending USSD string like:
*121*<pin_code>#.

Call to Customer Care

Certain CC Operators will be able to perform manual refills, when required,

depending on MINSAT assigned profiles.

3.6.2 Balance Inquiry/Notification

Subscribers can obtain information about balance by using following paths:

IVR

Call to IVR for balance inquiry will be available in CS3.0 solution.

USSD

USSD inquiry will be available in CS3.0 solution by sending Balance Inquiry

USSD string like: *123#.

Call to Customer Care

Upon subscriber request, CC Operators can use MINSAT GUI to obtain

subscribers information and notify to subscribers.

3.6.3 Charging System initiated voice announcements

Some voice communication announcements in Ericsson Charging System

Solution are initiated by the system itself, by SDP node. All used voice
announcements must be stored, by TELCO X, in the announcement machine
in the MSC.

Find below description of announcements that will be available.

3.6.3.1 Call Set-up Announcements

Call set-up announcements are the announcements played before the call is
set up towards the called party. The different kinds of call set-up
announcements are as follows:

Welcome Announcements: These announcements welcome a

subscriber to Charging System and are played once.
 Information Announcements: These announcements inform the
subscriber about the account balance. Special announcements, such
as advertisements, can also be played.

Warning Announcements: The subscriber has the possibility to be

warned in case the account or expiry dates are about to reach a limit
that will result in call cut-off or another restriction in using the account.
It is possible to play warning announcements as a tone.

Barring Information Announcements in case a subscriber is barred

from either reaching a specific number or using the subscription at all,
it is possible to play an announcement to inform the subscriber about
this.

3.6.3.2 In-Call Announcement

Charging System has one in-call announcement - a warning to the subscriber

when approaching the account limit, after which the call will be cut off. The
time between the warning and the depletion of the account is configurable in
one-second steps between the minimum of one second and a maximum of 60
seconds.

The in-call announcement is played to the Charging System subscriber.

During the announcement the other party is put on hold and the call is still
charged. Therefore, the announcement will not last long and it is normally
realized as a tone.

The In-Call Announcement will be played for TELCO X configurable seconds

before call disconnection for HPLMN calls.

3.6.3.3 End-of-Call Announcement

Charging System has one end-of-call announcement - the call cut-off

announcement which is played immediately before disconnection of a call. It
is used to inform the subscriber that there is either not enough money on the
account for the call to continue or that the subscribers credit limit has been
reached.

The call cut-off announcement is played to the subscriber that has run out of
funds. During the call cut-off announcement the other party is disconnected.
After the announcement has been played, the remaining call party is
immediately disconnected.

Note: If CAPv2 is used no cut-off announcement will be played.

3.6.3.4 Mandatory announcements

Find below list of mandatory announcements that will be configured in

Ericsson Charging System solution for TELCO X. These announcements
should be recorded in MSC.

Code Announcement When Played Used Phrase

6050, Barred due to no Call does not have Active `You are barred because
6150 Active Service Service though it is you have no Active
needed. Service.'
6055, Barred due to no Call does not have `You are barred because
6155 service (No Active Passive service though it you have No Service.'
and no Passive is needed.
Service)
6060, Operator barring of Active service or passive `Your service is barred.
6160 service service or both disabled Please contact the
flag set. service provider.'
6065, Account too low for Money taken from `Your account is too low
6165 call account is not enough for for the call.'
a 1 second call
6070, Destination number The called number is on `You are not allowed to
6170 in barring list the barring list call this number.'
6075, Warning of cut-off A configurable time Tone (Warning of call cut-
6175 tone before the call will be cut off)
off when account is
empty
6080, Terminating When active or passive `The destination you are
6180 call:Subscriber is service is not got though trying to call is not
not reachable needed at terminating reachable'
call
6085, Announcement at When the called party is `The call will be
6185 call cut-off disconnected due to that disconnected due to lack
account is empty of money.'
Announcement code numbers from 6150 to 6189 are the mandatory ones
used only for roaming.

The Used Phrase field is only and example, the text and the languages to be
used are configurable.

Note: The list of optional announcements to be used for TELCO X, was not
defined by the time this report was produced, and therefore it is not included
here.

3.7 Charging

Charging analysis is performed using a rating structure. The rating structure

has the form of a selection tree, and usually consists of several conditions
resulting in tariffs with rates and possible additional fees. See example below:
3.7.1 Charged Services

Charging for services described in this chapter will be performed in real time.

If a service or event, for some reason cannot be charged using online

charging, Charging System has the possibility to charge the subscribers
accounts offline by collecting and post-processing CDRs.

Find below additional information regarding each one of these services:

- Outgoing voice calls are charged in HPLMN using CS1+ protocol and in
VPLMN, using CAMEL ph 2.

Charge of outgoing voice calls when roaming using USSD Call Back will be
used in the VPLMN that Camel PH2 is not supported.

- Incoming voice calls when roaming are charged using CAMEL ph 2.

- Outgoing SMS is charged in HPLMN using CS1+ protocol and when

roaming using CAMEL ph 3 protocol. Outgoing SMS is charged upon delivery
to B-number

- MMS will be charged with Diameter SCAP in realtime.

Data traffic will be charge using SACC solution using Packet Inspection.

Note: Online Mediation Solution between SACC and CS is needed to adapt

versions of the diameter protocol for realtime Charging.
3.8 Customer Care

Customer Care personnel will receive complains or requests from customers

and will be able to check account status, account history and call history.

Operations that will be performed by CC from MINSAT:

Account Status query
Account History query
Call History query
Personal details query: Name, address, Social security

Operations that will be performed by Operations people upon CC request

from MINSAT:

SIM Swap
Balance enquiry
Manual Adjustments
Account Status query
Account History query
Call History query
Personal details administration: Name, address, Social security
number
Service changes (Service Class, language,..)
FaF administration
Remove IVR barring
Voucher Inquiry/Refill
Subscriber Re-activation

Operations performed by Operations people upon CC request from HLR

command line interface:

HLR services activation-deactivation: Outgoing-Incoming voice

calls, SMS, International calls, call diversion, call line
identification, etc.

All described operations performed with current system by CC people, and by

Operations people will be available in CS30 system through MINSAT. General
Menu screen can be found below:
 NOTE: Access to different functions in MINSAT can be controlled through
different access profiles depending on the user role. For instance: CC
operator, CC supervisor, etc. So that part of the operations currently
performed by Operations people could also be performed by CC people.
which could speed up process to handle complains and requests from
subscribers.

3.9 Reports
A number of statistics and reports can be generated from the data available
in Charging System. The statistics focus on statistical counters, whereas the
reports focus on business- and subscriber related information. For a detailed
overview of the statistics and reports generated in Charging System, refer to
the Overall Guide Statistics and Generation in CPI, Reference which also
includes references to the respective network element Users Guides where
information about administration of statistics and reports generation can be
found.

Generally, following Statistics and reports can be created for Charging

System 3.0.

Service Data Point (SDP) Statistics and Reports

Charging Control Node (CCN) Statistics and Reports
 Account Information and Refill (AIR) Statistics
Voucher Server (VS) Statistics and Reports
Mobile Intelligent Network Subscriber Administration Tool (MINSAT)
Statistics and Reports
Intelligent Network-Interaction Voice Response (IN-IVR) Statistics
IN Service Statistics and Call Reports
Hewlett Packard (HP)-IVR Statistics
Voice Extensible Markup Language IVR (VXML IVR) Statistics and
Reports

3.10 DR and CDR generation

In Ericsson CS3.0 solution it is possible to generate Detail Records in

MSC/SSF, CCN, AIR system, and the SDP depending on the traffic cases and
operators choice of configuration.

In addition to the more traditional call and account adjustment related Detail
Records, Charging System also provides Detail Record types that report a
certain account event, for example: Account created, Connected to or
removed from a multi-user account, MSISDN change, Lifecycle change,
Negative balance barred, Value voucher expiry and Voucher error.

In standard Ericsson Charging Solution, CDRs are routed to EMM (Ericsson

MultiMediation) which will do proper formatting and re-sending to
administrative system MINSAT, in order to provide call history for subscribers
as well as the other post-processing system like billing systems, DataWare
House Systems etc.

CDRs will be generated from following different nodes in the CS 3.0 solution:
The following DR types can be generated on CCN:

CCN CDRs contains the standard call data together with charging
information (Account balance before and after, etc) for Voice, SMS, Fax,
Data records with INServiceDataEventModule

is also being used for real-time charging of Originating SMS when

roaming via the CAP v3 interface. Therefore, the only CDRs generated
will be of type SCFSMSCSMORecord

DRs should be routed to EMM (Ericsson Multi Mediation) which will do proper
formatting and re-sending to administrative system MINSAT, in order to
provide account history for subscribers. DRs will be generated from following
different nodes in the CS3.0 solution:

The following CDR and DR types can be generated on SDP:

CDRProcessed, This record contains data for a post processed session.

AccountAdjustment, This record contains data for a balance adjustment
transaction.
NegativeBalance, This record contains data about when a negative balance
has occurred.
BonusAdjustment, This record contains data for an bonus transaction.
ServiceFeeDeduction, This record contains data about a service fee
deduction.
LifeCycleChange, This record contains data about the life cycle handling.
 NegativeBalanceBarred, This record contains data about an account that has
been barred due to negative balance.
ValueVoucherExpiry, This record contains account data about the status
when a value voucher expires.

The following DR types can be generated on AIR:

AdjustmentRecord, This record contains DR data for a balance adjustment

transaction.
PromotionRecord, This record contains DR data for an offline promotion
transaction.
RefillRecord, This record contains DR data for refill and voucher refill
transactions.
ValueVoucherRecord, This record contains DR data for a service class
change transaction, that is initiated by a value voucher refill.
ErrorRecord, This record contains DR data for an unsuccessful transaction.

Hot billing will be available through CDR processing feature. It will be used in
case any service cannot be charged in real time or for CDR post-processing
in case on network failure. For such functionality CDRs will be sent from EMM
to SDP which will perform the proper charge to the subscribers accounts.

Further information regarding CDRs format can be found in CPI library

documentation for CS3.0:

Overall Guide CDR Configuration,

Detailed Record Parameter List, Data Record Output SDP,
Detailed Record Parameter List, Charging System CCN CDR,
Detailed Record Parameter List, Data Record Output AIR,
Detailed Record Parameter List, CCN-CDR,

NOTE: additional CDRs can be generated in CCN, GGSN and MMC in when
data services are activated.

3.11 Roaming

TELCO X will use following roaming enablers in order to provide roaming

services to subscribers:

o Camel ph 2 for voice calls

o Camel ph 3 for Originating SMS

NOTE: USSD CB feature, will be used for roaming in the VPLMN which
Camel is not supported.
3.12 O&M Procedures

Main operation procedures are related to subscribers and voucher

provisioning, and have been described in previous chapters.

Daily, weekly and monthly maintenance routines and Operation procedures

are defined in Overall Guide Charging System Administration in CPI library for
CS3.0 solution.

Following user interfaces can be used as part of the standard Ericsson

Charging System 3.0 implementation:

SDP User Interface

All SDP administration, such as tariff handling, service class administration,

and software administration is performed through a Java-based GUI.
See SDP Users Guide Service Class Administration and SDP Users Guide -
Selection Tree Administration, in CPI library for detailed information.

ADMIN User Interface

Subscriber administration in the Administration Systems is performed through

browser-based HTML/Java-script GUIs.
See MINSAT Users Guide Batch and Service Administration in CPI for
detailed information.

CCN User Interfaces

CCN Manager

How to create and maintain the configuration of a CCN using the CCN
Manager Graphical User Interface (GUI) is described in the CCN Manager
User Guide, in CPI library. It also describes how to view configuration data for
a particular service in the system.

Node Management Toolbox

For the operation and maintenance of the TSP platform, the Node
Management Toolbox is also used.
The JXplorer LDAP browser is the GUI for managing the CCN service and its
features.
The browser is started from the O&M Toolbox, which is delivered with the
TSP. The JXplorer LDAP browser provides a hierarchical tree structure view,
which shows the installed services and features on the Application Server. It
enables the System Administrator to add or delete services and features and
it offers the possibility to search for a specific object.

IVR User Interface

The HP-IVR functions such as call flows are managed by a Java based web
GUI.

AIR User Interface

 All administration of the AIR system is performed by using a Java-based GUI.
Through the AIR user interface it is also possible to access a number of files
in the AF.
See AIR Users Guide Service Configuration Administration, in CPI library for
detailed information

VS User Interface
All VS administration is performed by using a Java-based GUI.
See VS Users Guide Voucher Administration, in CPI library for detailed
information

3.13 License Management

License management in Charging System is related to both the allowed

number of subscribers, and the right to use optional features. The commercial
agreements are enforced by a license server, which manages a set of license
keys. The license key is encrypted and located in a Sentinel-license server
located in one of the SDPs. The network elements involved are SDP, AIR and
VS.

ADMIN provides its own licensing, depending related to both number of

subscribers and functionalities used.

It is possible to run Charging System on trial without a license for seven days,
enabling test of, for example, extra capacity.

Initial license configuration is done at installation.

For more information about license management, see Overall Guide

Charging System Administration, in CPI library.

3.14 Fault Management

The purpose of fault management is to report detected failures, and to limit

the failures effect on the network performance as far as possible.

All network elements automatically create and send alarms and events to the
Ericsson Operation- and Support System (OSS) which provides a centralized
alarm view of a mobile network.

Below picture shows a diagram of connections from different nodes in

Ericsson CS3.0 to Ericsson OSS, for fault management.
Each alarm or event is described, per network element, in its own Alarm and
Event Description document, which can be found in the CPI library.

Ericsson OSS offers several interfaces to be used for network elements

issuing alarms. Dependent on network element type, the network elements in
Charging System uses two different alarm interfaces:

TMOS Text File Adaptation (TXF)

Simple Network Management Protocol (SNMP)

For Solaris based network elements the hardware and the operating system
are supervised by a solution based on SunMC. Detected faults are processed
by a Charging System specific application on the SunMC server and sent to
the Ericsson OSS using TXF.

For TSP based network elements one alarm interface is supported, SNMP.
4 Terminology

AIR Account Information and Refill

AF Account Finder
ARPU Average Revenue Per User
ASCS Administration System for Charging Systems
BHCA Busy Hour Call Attempt
CA Customer Adaptation
CAI Customer Administration Interface
CAMEL Customized Application for Mobile Enhanced Logic
CC Customer Care
CC-API Customer Carer Application Interface Protocol
CCBS Customer Care and Billing System
CCN Charging Control Node
CDR Call Data Record
CPI Customer Product Information
CPS Calls Per Second
CS Charging system
CS1+ CS1+ Ericssons IN protocol supporting all capabilities of
DNS Domain Name Server
DR Data Records
EMA Ericsson Multi-Activation
EMM Ericsson Multi-Mediation
EoCN End of Call Notification
ERE Ericsson Rating Engine
ERS Electronic Recharge System
FaF Friends and Family
FBC Flexible Bearer Charging
FTP File transfer protocol
GGSN Gateway GPRS support node
GPRS General Packet Radio Service
HLR Home Location Register
HTTP Hyper text transfer protocol
HW Hardware
INAP Intelligent Network Application Protocol
MAP Mobile Application Part
MSC Mobile Services Switching Centre
MSISDN Mobile Station International ISDN Number
OSS Operations Support System
RPC Remote procedure call
SC Service Class
SCF Service Control Function
SCP Service Control Point
SDP Service Data Point
SMAS Service Management System
SMS Short Message Service
SS7 CCITT Signaling System Number 7
SSF Service Switching Function
TCP/IP Transmission control protocol/Internet protocol
UCIP User Communication Interface Protocol
USSD Unstructured Supplementary Service Data
VoIP Voice over IP
VMS Voice Mail Service
VS Voucher Server
 XML Extensible mark-up language

5 References

[1] SDP User's Guide Selection Tree Administration, Ref. 2/1553-CSH

150 25/2
[2] USSD User Event Notification FenD, Ref. 1551-FAJ 201 602/1
[3] MINSAT User's Guide Service Management and Statistics, Ref.
3/1553-CSH 109 80
[4] MINSAT Programmer's Guide Customer Care API 5/1553-CSH, Ref.
109 80 Uen
[5] Overall Guide CDR Configuration, Ref. 4/1543-HSC 120 13/1 Uen.
[6] Detailed Record Parameter List, Data Record Output SDP, Ref. 190
59-FAY 302 22/1 Uen.
[7] Detailed Record Parameter List, Charging System IN/PSL CDR, Ref.
190 59-FAY 302 26/1 Uen.
[8] Detailed Record Parameter List, Data Record Output AIR, Ref. 190
59-FAY 302 35/1 Uen.
[9] Detailed Record Parameter List, CCN-CDR, Ref. 190 59-FAY 302
09/1 Uen.
[10] Overall Guide Charging System Administration, Ref. 1/1543-HSC 120
13/1 Uen
[11] VS User's Guide Voucher Administration, Ref. 1/1553-CSH 150 28/2
[12] MINSAT 5.2 User's Guide Service Management and Statistics, Ref.
3/1553-CSH 109 80 Uen