Rating

BSCS --Business Support and Control System

 Business Support and Control System (BSCS) is an end-to-end customer care

and billing system, designed to deliver across all wireless and wireline networks
in the worldwide marketplace. It supports your move into new territories, such as
Internet and new-generation telecom technologies.

 Description:
 The rate plan that is applied to calculate usage charges and the party, who has
to pay for a particular call or event, is defined by means of system scenarios,
which are set up in Product Center (PX) for the internal record format UDR.

 Functionality Of MEDIATION:
 PULL--- It collects CDR from network
 PUSH---pass it to the downstream system

 Cust_code: unique customer code we can identify the customer type.in BSCS
 Individual customer code start with 1
 Enterprise/co-oprate cust code start with 2, 3….8.

 The business partner code is created automatically when the data of a new
business partner is saved for the first time. It is a unique code used to identify the
business partner and starts with the number 1.
 Rating batch process

 DIH-- DEVICE INPUT HANDLER

 FIH --FILE INPUT HANDLER
 AIH --ASSEMBLY INPUT HANDLER
 PRIH-- PRE RATED INPUT HANDLER
 RIH --RATED INPUT HANDLER
 FOH --FILE OUTPUT HANDLER
 RLH --RATE LOAD HANDLER
1) Process Name :DIH Device Input Handler (DIH)
2) Functionality :
a) A BSCS back-end application which copies the files containing the CDRs from
the MSC to the BSCS working directory.
b) Data retrieve from network & store them into predefined directory of BSCS.
c) It can directly retrieve from mediation / Network.
d) Check naming conventions--valid files are copy to FIH input files
e) Supports multiple switches (Switch -network element)
F) DIH scan input directory if it found wrong file name convention (not in proper
format) it will reject that file else it will register that file into BSCS directory.

 FTAM FUNCTIONS- we can take file from network --file transfer-- for different
switch different script --transfer mode
 When FTAM functions are activated, DIH retrieves the CDR files directly from the
switch. This is done by calling a UNIX shell script, which has been setup uniquely
for each single switch. The UNIX shell script contains all relevant information and
parameters for a successful data transmission.

3) IMP Tables:
 IMP_FUNCTION_CONTROL TABLE-- script for particular switches—validation
type of file-switch & files identification—file name pattern.
 THSFTAB-input directory (file store location)-input file type –pattern.

Reference Data Tables

Database Table Description

THSFTTAB DIH looks up this table to determine the
switch that generated the CDRs and the
corresponding output directory. Only one
entry for the Billing Gateway is required.
THUFITAB DIH registers the input files in this table
making them available for the BSCS rating
chain.
IMP_FUNCTION_CONTROL DIH scans this table to identify where the
import files are located, the filename
structure and file type.
IMP_FTAM_CONTROL Control table for the import of CHUs with
the FTAM Front-end.

4) Calling up the Program :

 We start DIH with
 Rating manager--dih--start
 Mou1-rating manger functionality is available
 dih[-i][-r|d][-s<sleep seconds>][-l<Bytes_per_seconds>][-t][-n]
 I-version of BSCS/DIH
 -r=rename
 -l=lower transfer rate file process/per sec.
 -t=trace
 -s=sleep seconds [(if no file found in directory then it is goes to sleep mode
(7200sec default mode))]--
(7:40)
 -s =Sub trace
 -d=default/delete

1) Process Name : FIH – FILE INPUT HANDLER

2) Functionality :
a) Check files duplication.
b) Process on file which receives from DIH.
c) Single entry should be in THUFITAB table with status 0 so it will process
otherwise it will drop that file
d) FIH process checks duplicity in 2 ways:
I) Record level--- it checks whether we are doing rating for the same record
II) File level—it checks whether we are doing rating for the same file

e) CDR’s are converted to UDR (market independent format)

The individual Call Detail Records are checked and converted to a network-independent
format (UDR).

I) CDR --Call Detail Record

 It contains call details (call type, time, duration, facilities used, originator,
destination, etc.)
 BSCS receives CDRs as unrated calls, converts them to an internal format and
hands them over to rating for further processing.

ii) UDR – A UDR contains network-originated information about a call (network

subscriber ID, calling party, called party, call type, etc.) plus other default data

UDRs can be enhanced with charging and free unit information. Their variable structure
increases the flexibility of rating and billing and replaces the fixed structure of UTX and
RTX files. The system scenarios refer to UDR fields and attributes.

UDRs are generated from CDRs and IPDRs created by the network switch and from TAP files.
They contain all information required to identify the customer, services used, and to apply
charges.

 Switch captures the file in different format.

(19:20)
 Record update with status 7

3) IMP tables:

 One entry in the THUFITAB table for each input file.

 THUFITAB.STATUS = 0, indicating that the file has not been processed yet.

 Switch files:

 If there is an entry in the IMP_FILE_STATISTIC table with the current input file
ID (THUFITAB.FILE_ID = IMP_FILE_STATISTIC.IMP_FILE_ID) and the first
and the last call dates are the same as the respective call dates of the current
file, the current file is duplicate.
 If there is an entry in the MPUIHTAB table with the same PLCODE and file
sequence number as the current file, the current file is duplicate.

Mediation converts the files which are received from switch into BSCS understandable
format.

  Reference Data Tables

Database Table Description

MPSCFTAB A general BSCS iX Release 2 configuration table.
THSFTTAB The file types and sources of the tapes that can be
processed by Table Extraction Handler (TEH) are
specified here.

The column BLKSIZE allows you to set up the block

size for each file type supported by the system.

This table also specifies the kind of mapping of UDR

or BIR input files from 3rd party rating engines.
BSCSPROJECT_ALL The DUPLICATE_RECORD_CHECK_IND flag
controls the Duplicate Record Check.

  Working Data

Database Table Description

EXCHANGE_FORMAT Used to assign the correct converter for the
current input file.
THUFITAB From this table FIH gets information about the
input files. The field STATUS is set to the
following values:

 2 if the file was processed successfully

 1 if the file was processed unsuccessfully

 otherwise it is set to 0

MPUIHTAB Exchange files history table. For the long distance

carrier exchange files an additional entry is
inserted here.
MPUERTAB The error statistics table. FIH inserts an entry in
 this table if the input file contained errors.
MPDRCTAB The reason code table. FIH fills this table if error
reason code is absent in the MPDRCTAB table.
MPURHTAB Roaming Agreement history table.
IMP_CHANNEL_TABLE This table contains information about the
mapping of input files from 3rd party rating
engines.
IMP_FILE_STATISTIC Stores statistical data about processed records in
each imported CDR file:
IMP_CHANNEL_TABLE Assign the adequate
import channels for UDS_CONTEXT.

C)MPUIHTAB table

(2240)

 PL CODE -unique ID -network identification

 Dih-->FIH input --->0
 Reject –1
 FILE successful Process—2
 Partial—7

 bscsproject_all .duplicate_record_chk_ind -- table

1) Process Name: PRIH—PRERATE INPUT HANDLER

2) Functionality: PRIH helps to RIH to Rate the events .When CDR forwarded by FIH it
doesn’t include customer data like rate plan,

PreRate Input Handler (PreRIH) receives the call details record in the form of a usage
data record (UDR) from either File Input Handler (FIH) or from Assembly Input Handler
(AIH) if the call detail record entered the BSCS system as a partial record.

 PreRIH carries out the preliminary categorization and routing of the incoming
UDRs.

 It inserts the contract information in the UDRs and identifies the impacted parties,
for
example, home subscribers, roaming partners, interexchange carriers, or service
providers,
 As configured in the pre-business scenarios.

 Process on CDR’S which receives from FIH .

 Max age define as 90 days ,so we can only process on 90 days CDR.

 All data related to call for e.g. calling party, called party, duration of call, address
(zone).
  It prepares call related data for RIH to identify/calculate rate plan .

 We can run with the help of rating manager script only on mou1.

 On other Mou we have to start with manually if rating manger script is not on
other mou.

3) Calling up the Program:

 prih> [-a<n> -e -t -T<filename> -w<basedir>] [-r<n>] [-i]

4) IMP Tables:

PRIH_STATATICS TABLE – This table stores all info like, total no of records, no of
rejected records, processed records and successful records.

1) Process name: RIH-- RATE INPUT HANDLER

2) Functionality:
a) Rate to customer on the based on information (customer contract, rate plan,
and zone) which receives from PRIH
b) UDR is converted into RTX (RATED TRANSCATION) format
c) A BSCS back-end application in the rating area which calculates the charge of
each CDR ,after processing by RIH, the records are known as RTX records. As
with FIH.
c) RIH also performs rating for most business partners such as roaming partners,
service providers.
d) RIH rates call records that were created for subscribers and business
partners.
 RIH_STATATICS TABLE –

 RTX Records :Rated Transaction

 The name of a CDR after message processing. It is the BSCS supplier-
independent internal format which is passed on to the billing part of the BSCS
batch processes.

 CUG (close user group) PLAN

 A group of subscribers who have restricted access to other members of the
network. A subscriber who is a member of a CUG can only communicate with
other members of the group, but not with users outside the group.
 Also filter out 0 rated transactions (800)

I) Rate cycle—we can start 1 or more instance for speed up of rating for PRIH &
RIH

 Instance
 Parallel rating –set of customer for home subscriber can be divided into several
rate cycle.
 Each rate cycle is process by 1 RIH & 1 PRIH instance based on this we can rate
Number/Bulk of customer.
 Parallel rating flag is defined in BSCS_PROJECT _ALL (table) .parallel naming
(column name)
 FETCHER –Fetcher transport data to patcher, to the concat Script and to the
ASCII converters.
 Fetching data from mount point and deliver this to the individual input modules of
the BSCS take place through Fetcher script.
 Co (voice call) forwarded to the patcher- -after processing this goes to DIH
 G1 (GPRS FILES) goes to the concat script -- after processing this goes to DIH
 S1 (content files) goes to ASCII converter
 Fetcher  co (voice call) patcher processing DIH
 Fetcher G1 (GPRS FILE)  CONCAT(PROCESS) fetcher patcher
DIH
 CONCAT -big file size are separated into small file size /small size file are fit into
big file size
 Concatinputfiles.pl[parameter]
 Fetcher  S1 (MMS content files) ASCII DIH

o Notes:
o Recording type 32: Normal GPRS files
o Recording type 34: Roaming GPRS files
o Recording type 121: MMS content provider Files
1) Process Name: Rate Load Handler (RLH)

2) Functionality:

 RLH is a permanently running process which performs the following tasks:

 Loads postpaid UDRs generated by RIH instances into the RTX database, where
Billing Cycle Handler (BCH) and Customer Center can access them.
 Performs open amount checks and contract credit checks.
 Applies free units of measure (FUoM)
 Loads the UDRs generated from prepaid CDRs into the RTX database. For
postpaid records, RLH does not perform the following tasks in the case of
prepaid records:

o Update unbilled amounts.

o Perform credit threshold limit checks.

o Maintains history tables for business partner billing.

Imp table - rtxcytab table

1) Process Name: MIH --- Motivation Incentive Handler

2) Functionality:

 Motivation and Incentives Handler (MIH) is the basic promotion engine of

BSCS .The data exchange between BCH and MIH is provided by a direct call
interface. The essential parts of the library are processes that initialize and
terminate the engine, that apply promotions to customers and that describe the
transferred data.

 MIH forwards the results of the processing of promotion packages that have
actually been applied to BCH, together with the promotion details that can be
included in the invoice.

 MIH permanently stores the altered or new information if it is a regular billing run.

1) Process Name: TEH (Table Extraction Handler)

2) Functionality:

 Table Extraction Handler (TEH) loads reference data from the main database,
performs some preprocessing functions, and stores the extracted data in the
UNIX file system in predefined files known as cross-reference files (Xref files),
 Each carrying the content of a cross-reference table (Xref table) or simply Xref.
Often the term Xref file appears as a synonym for Xref table.
 TEH consists of a Pre Table Extraction Handler (PreTEH) and subsequent TEH
processes. PreTEH is the supervisory process for the TEHs.

The main task of TEH is to provide updated data to time-critical applications like the
applications in the message processing chain:
  File Input Handler (FIH)

 Rate Input Handler (RIH)

 File Output Handler (FOH)

 Bill Cycle Handler (BCH)

 These applications repeatedly need access to substantial amounts of current

database information. Instead of accessing the main database directly, however,
they load this information into memory from the Xrefs created by TEH. This
method keeps processing times considerably shorter and increases
performance.

1) Process Name: Xref file

2) Functionality:
 The Xrefs are snapshots of the main database; they are not immediately altered
when the database content changes.

 A file extracted from the database by TEH, containing selected information from
various tables. For performance reasons, several other batch processes read the
Xref files, instead of accessing the database directly. It is also referred to as Xref
file.

 In EI it can be specified whether BCH takes the data from the billing Xref table or
from the database.
1) Process Name: Generic Mediation Device (GMD)

2) Functionality:

 Generic Mediation Device (GMD) is based on client-server architecture. It

establishes a platform on which vendor-specific mediation devices can be
coupled with BSCS without being effected by the BSCS -internal application logic
and data formats.
 GMD forwards changes that are requested by the customer care system to either
the appropriate components of BSCS (using RDRs), to the network (using
EDIFACT) or to both of them depending on the type of request.

 Customer- and contract-related, for example, a customer moves to another family or the rate
plan of a contract is changed.

 Network-related, for example, the change of an MSISDN.

1) Process Name: RDR --reference data record

2) Functionality:

 A unified data record (UDR) variant which contains information about the current
subscriber and contract changes. It is generated by GMD and processed by
RDH.
 When GMD receives a customer- or contract-related change request it creates
an RDR and sends it to the rating applications which require knowing of such
changes.
 To avoid the loss of free units, all changes to free unit reference data (product
data and customer data) are sent to Rate Load Handler (RLH) using RDRs.
 RDRs are created by GMD each time customer- and contract-specific data is
changed in Customer Center.
1) Process Name: RDH -- Reference Data Handler

1) Functionality:

a)A back-end application which extracts reference data (product as well as

contract and balance data) from flat files and loads it into the shared memories of
PreRIH, RIH, RIHEC, EVH, PreCCH and CCH.

 This is done for performance reasons, so that the rating and balancing processes
do not access the database directly. RDH first deals with the Xrefs (see Xref
table), then the balances from Oracle and then each RDR.

1) Process Name: Data Transmission Application (Data)

2) Functionality:

 The Data Transmission Application (Data) server is an information hub reliable

and highly available data and information transfer between the interested
component applications. The Data server instances and the applications can be
distributed over different nodes in a multiple network environment.
 Data utilizes the Data Transmission Library (DXL). The DXL is responsible for
packaging and forwarding the data from the concerned applications to Data and
vice versa.

1) Process Name: Data Monitor Handler (DMH)

2) Functionality

 Data Monitor Handler (DMH) is a tool used to generate reports about all queues
created by the Data server.
 It provides the ability to check the internal states of Data and allows the starting
or stopping of queues that belong to a certain profile.
 The information, on which queues have to be initially stopped, is taken from the
BSCS database via an environment variable.
 Changing the setting will be done by starting DMH with appropriate command
line parameters (refer to Starting via Command Line for more information).