6 About the Convergent Charging Controller System Architecture
This chapter provides an overview of the Convergent Charging Controller system architecture.
About the Convergent Charging Controller System Architecture
Figure 6-1 depicts the main components of the Convergent Charging Controller system architecture.
Figure 6-1 Main components of the Convergent Charging Controller system architecture
These components perform the following tasks in the Convergent Charging Controller application:
-
Service Logic Controller (SLC)
-
Service processing for voice calls, SMS text messaging, and data content
-
Network communication
-
-
Voucher and Wallet Server (VWS)
-
Prepaid rating
-
Balance management
-
Voucher management
-
Promotion tracking
-
Synchronization with a secondary VWS server in a VWS domain
-
-
Service Management System (SMS)
-
Data storage
-
Data replication
-
System administration
-
-
Oracle's Billing and Revenue Management system or a 3rd party billing system
Tasks that an external billing and revenue management system can perform include:
-
Voucher management, and other features that overlap with VWS
VWS might not be needed with a 3rd party billing system.
-
Customer management
-
Creation of price lists for services
-
Rating and calculation of charges
-
Billing, payment management, and accounts receivable
-
The following sections describe these components in more detail.
About the Service Logic Controller
Figure 6-2 depicts the Convergent Charging Controller Service Logic Controller.
The Service Logic Controller (SLC) has the following components:
-
Service Logic Execution Environment (SLEE)
Routes calls to Advanced Control Services (ACS) and to the appropriate Convergent Charging Controller components by way of the SLEE interfaces (Transaction Capabilities Application Part (TCAP) and Billing Client).
The main SLEE process, which handles requests between the network and the SLEE, is the slee_acs process.
-
Charging Control Services (CCS)
Provides the charging control logic and tools.
-
Advanced Control Services (ACS)
Provides the real-time engine for control plan execution, which is effectively the call processing engine.
-
Network connectivity agents (NCAs)
NCAs provide interfaces for slee_acs and the rest of the SLEE for the various protocols running on the network. NCAs translate the particular network protocol to the Intelligent Network Application Part (INAP) protocol, which is the internal protocol used by slee_acs.
-
Billing Client
Provides the interface that processes requests from the call processing engine to the Voucher and Wallet Server or an external billing system.
About SLEE
The Service Logic Execution Environment (SLEE) provides a common run-time environment for various service logic applications that communicate with each other through events and interface with external networks and applications. The SLEE manages components on both the SLC and VWS servers.
At a high level, the SLEE considers any voice or data call, SMS text message, or type of business logic as a call instance having source and destination addresses for a communication channel, which it uses to pass data or events back and forth and to other Convergent Charging Controller applications. The SLEE routes calls to Advanced Control Services (ACS) and to other machines through the TCAP and Billing Client interfaces.
About Charging Control Services
Charging Control Services (CCS) is effectively the Convergent Charging Controller prepaid charging component that allows you to create the following entities:
-
Subscriber accounts and wallets
-
Product types to be associated with the subscriber wallet
CCS allows you to customize call processing based on factors such as:
-
Geography
-
Demographics
-
Resources
-
User preference
CCS is installed on all three Convergent Charging Controller servers: SLC, SMS, and VWS.
About Advanced Control Services
Advanced Control Services enables you to configure processing and routing for calls to or from a specific number or for calls triggered for a specified INAP service key. You configure call processing and routing through a control plan. Essentially, ACS is the real-time engine for executing a control plan.
You create control plans by using the Control Plan Editor (CPE), which is a graphical user interface that allows you to diagram the flow of a call through a series of feature nodes. A feature node defines a possible action related to call processing such as determining the rate based on the day of the week or time of day, or playing an announcement, or forwarding a call to a different number. The CPE provides a rich variety of feature nodes on a feature palette. From the feature palette, you select the icons for the feature nodes that you want to use to implement in the control plan. Each feature node has a single entry point and one or more possible exits. Each exit can lead to another feature node in the control plan until the end feature node is reached.
About Network Connectivity Agents
Table 6-1 shows a sample of network connectivity agents, listing the name of the connectivity agent, the network protocol that the agent handles, and the type of communication that the agent handles.
Table 6-1 Network Connectivity Agents
| NCA | Protocol | Type of Communication |
|---|---|---|
|
DCD |
Diameter (out) |
Used for processing of Diameter-based billing requests. Supports RFC-3588 and RFC-4006 protocols. Acts as Diameter client. |
|
DCA |
Diameter (in) |
Used for processing of Diameter-based billing requests. Interfaces with MMSC/SMSC/GGSN. Provides an interface to Prepaid Charging. Acts as a Diameter server. |
|
Messaging Manager |
MAP (Mobile Application Part protocol) |
Supports roaming, authentication, subscriber tracing, and so on. |
|
SCA |
SIP (Session Initiation Protocol) |
Used for real-time charging, instant messaging and personal mobility in SIP-based Next Generation Networks (IETF/ETSI NGNs) and in the IP Multimedia Subsystem (3GPP IMS, 3GPP2 MMD). |
|
Messaging Manager |
SMPP (Short Message Peer to Peer) |
Used for sending SMS messages between peer SMS entities and message centers. |
|
SIGTRAN |
SIGTRAN |
Used for converting messages arriving from the TCAP protocol stack into SLEE events. |
|
TCAP_IF |
XML/TCAP (Extensible Markup Language/Transaction Capabilities Application Part) |
Supports multiple concurrent dialogs between SLEE, ACS, and other servers. |
|
UIS |
USSD (Unstructured Supplementary Service Data) |
Supports USSD messages between mobile devices and Convergent Charging Controller; supports menu-driven and interactive services. |
|
OSD |
SOAP/XML (Simple Object Access Protocol) |
Supports exchange of messages in XML format between web services. |
|
IS41 |
IS41 (Interim Standard 41, also known as ANSI 41) |
Supports interoperability between differing mobile telephony networks, providing capabilities for intersystem handover, subscriber detection and authentication, and so on. |
About the Service Management System
Figure 6-3 depicts the Service Management System.
The Service Management System (SMS) server is primarily the repository for the SMF database, which provides centralized storage for customer data, logs, alarms, and statistics. The SMS replicates data that is needed by the SLC and VWS servers, such as subscriber and wallet data and tariff and rate tables.
The SMS also provides a built-in customer relationship management (CRM) system that you can provision directly or through an external provisioning interface. It also includes a graphical user interface that provides you with access to data that the service logic applications use.
Figure 6-4 shows the SMS Services menu in the SMS GUI, which lists the services that SMS makes available:
Figure 6-5 shows the Operator Functions menu in the SMS GUI, which lists the types of operator functions that SMS makes available:
About the Voucher and Wallet Server
In a redundant configuration, two Voucher and Wallet Servers, a primary and a secondary, make up a VWS domain. In normal conditions, the primary VWS performs all subscriber account, wallet, and balance actions for the pair and the secondary VWS maintains a duplicate set of data.
Figure 6-6 illustrates the data flow in a VWS domain.
Figure 6-6 Data Flow in a Wallet and Voucher Domain
The following components play roles in processing requests from the Voucher and Wallet Server.
-
BeClient
The BeClient process is any process that uses the libBeClientIF library to connect to the beServer.
The main BeClient process is the one provided for the SLC.
-
beServer
Handles all requests from the SMS and SLC servers and can be extended with plug-ins. Handles connections from client processes (including BeClient processes) and controls routing to beVWARS processes.
-
beVWARS
The beVWARS process is the engine of the VWS. Usually, more than one beVWARS process runs on a VWS. It reads and caches wallet and voucher information from the E2BE database and manages all queries, reservations, and updates against wallets. It also manages all queries, redemptions, and state changes for vouchers. It initiates data synchronization with a secondary VWS and writes event detail records (EDRs).
-
beVWARS handlers
Perform business-case specific operations on wallets and vouchers. For example, CCS handlers manage monthly spend accumulation and upgrade, and account activation. Some handlers are provided by VWS, but other applications can extend VWS logic by providing additional plug-ins.
-
beSync
Synchronizes data between the Voucher and Wallet Servers in a VWS pair.
-
E2BE database
The databases on the VWSs, which also hold a subset of the data from the SMF.
Other applications may provide other processes to handle other activities, such as ccsBeOrb, which handles interaction between the SMS screens and the Voucher and Wallet Servers.