You are on page 1of 5

Interconnect Rating Flow

➢ Mediation process “readgfile” mediate and decode RAW CDRs comes from NE and then reformatting
and apply filtering rules matching rating engine format.

➢ FILEREG process registers the ASCII files which come from mediation server with status 30 (i.e. field
BI_AUTO_STATUS in DBM_CDR_HEAD table) as initial status for rating engine.
➢ Rating engine DBMDBT
o fetches all files located under $NEW folder on OS,
o sets the file status to 30,
o starts loading the setups and tariffs
o applies proper tariff to each call according to predefined configurations*,
o according to DBMCHGR screen setup, creates temporary table to insert all rated CDRs data in
it,
o suspends CDRs if any setup or configuration is missing.

(All suspended CDRs data go into DBM_BIAUTO_SUSP table.)

[* Predefined configurations and setups can be found in following tables:

▪ DBM_CALLTYPE_PARAM
(This table contains all call types and is used as lookup table.)

▪ DBM_CDR_FIELDS
(This table contains details of all CDR attributes.)

▪ DBM_CDR_GROUP
(This table contains rating rate plans with Priority 1 as high, 2 as low and so on.)

▪ DBM_CDR_GROUPS_TYPES
(This table contains rating plans with subscriber’s type "G" as GSM, "W" as wireless, etc.)

▪ DBM_CHARGE_GROUP_DEF
(This table links charge groups and rating plans and has description for each charge group.)

▪ DBM_CHARGE_GROUP_DETAIL
(This table links charge groups and rating plans with effective date and stop date.)

▪ DBM_CDR_GROUP_DETAIL
(This table contains rating plan and the reference for each CDR FIELD used within the rate plan.)

▪ DBM_CHARGE_GROUP_DATA
(This table contains the values of charge group’s details like CALL_TYPE and PP_FLAG and so on.)

▪ DBM_RATE_GROUP
(This table contains tariff groups and is used as lookup table)

▪ DBM_PEAK_OFFPEAK
(This table contains tariff class details and is linked to tariff profile, tariff group and time intervals.)

▪ DBM_BIDEST
(This table contains all destination codes and their links to charge group and tariff group.)

▪ DBM_RATE_TARIFF_GROUP
(This table contains original tariff groups and sub-tariff groups.)

▪ DBM_BIRATE_HEAD
(This table contains tariff groups linked with customer tariff profile)

▪ DBM_BIRATE_DETAIL
(This table contains tariffs’ details and the rate per period for each tariff group, tariff profile, tariff class
and charge type.) ]
When DBMDBT starts processing a file, it goes through the following steps for every CDR in the ASCII format
available after a filtering process:

▪ Checks if the CDR follows a pattern of a special charge group, if found, it will mark this CDR with this
charge group, otherwise it returns no charge group (default charge group).

Example: Fetch the actual values for each charge group from setup table BM_CDR_GROUP_DETAIL where you find values
defined for rate plan of roamer outgoing local:

This rate plan has 3-charge-group criteria to catch its actual charge group field id 30 for call type, 180 for
LONG_NUMBER_TOF and 1700 for PP_FLAG as per below screenshot:

The actual values are defined within DBM_CHARGE_GROUP_DATA, for example, if the CALL_TYPE = ’001’ and
LONG_NUMBER_TOF = ’00’ or ‘02’ and PP_FLAG = ’POST’, the rating will catch charge group RMLOCAL:

▪ Checks the type of call and the destination.

[The Call Type titles are defined as configuration in DBM_CALLTYPE_PARAM table but the actual Call Type values are
defined within tariffs’ setup in DBM_CDR_GROUP_DETAIL table. Destination Codes are defined in DBM_BIDEST
TABLE.]
▪ Maps the charge group and the destination to the tariff group.

Example: Let’s take an example of a Roamer’s Outgoing Local Call:

Fetch the actual values for each charge group from setup table DBM_CDR_GROUP_DETAIL, where you will find
values defined for rate plan for roamers’ local outgoing:

This rate plan has 3-charge-group criteria to catch its actual charge group field id 30 for call type, 180 for
LONG_NUMBER_TOF and 1700 for PP_FLAG as per below screen shot:

The actual values are defined in DBM_CHARGE_GROUP_DATA table. For example, if the CALL_TYPE = ’001’ and
LONG_NUMBER_TOF =’00’ or ‘02’ and PP_FLAG = ’POST’; the rating will catch charge group RMLOCAL.

After fetching the value for charge group, check the current destination code which comes as part of CDR within the
ASCII A file. If the current BSUBNO starts with one of the below DEST_CODE, assign the charge group RMLOCAL
(CHARGE_FLAG on DBM_BIDEST TABLE) and DEST_CODE to tariff group GRMARB1:
▪ Map the tariff group and the customer tariff profile to locate the tariff plan.

[You can get Customer Tariff Profile from CRM_USER_INFO table and get Tariff Plan from
DBM_BIRATE_DETAIL based on Tariff Group, Tariff Class (Peak / Off peak), Tariff Profile and Call Duration.]

▪ Rate the call and store it in the proper table*.

[* It's a temporary table created by rating engine, having the same name as CDR file name.]

▪ Update the file status into 90.

▪ Move the A file* into $OLD after processing the file.

[*The ASSCII file registered on DBM_CDR_HEAD under BI_FILE_NAME field.]

➢ CHKDUP process, fetch all files have status 90 and then then start verifying the temporary table to
check for duplicate CDRs and then remove the duplicate CDRs and achieve duplicate CDRs into
dbm_dup_loc table and remove duplicate CDRs from temporary table. After that update file status on
dbm_cdr_head table to 91.

➢ IAAHIST process, fetch all files having status 91 and IAA_CALL =null on dbm_cdr_head table and then
start achieving them into IAA_HISTCALLS table. After processing, the files update their status into 92
and IAA_CALL to have “Y”.

➢ IAADAILY process, fetch all ratable text file in DBM_CDR_HEAD with status=92 and having
ID_DAILY=null has the records in the corresponding temporary table and aggregate them and then
insert aggregated CDRs into IAA_DAILY table. After IAADAILY aggregate daily CDRs into iaa_daily table,
it update the flag ID_DAILY=”Y” for the record with bi_file_name on dbm_cdr_head table and then
update file status to 93.

➢ IAAMONTHLY process, fetch all ratable text file in DBM_CDR_HEAD with status=93 and having
ID_MONTHLY=null has the records in the corresponding temporary table and then aggregate them
and insert them into iaa_monthly table. After IAAMONTHLY finish processing the files, it update the
flag ID_MONTHLY=”Y” for the record with bi_file_name to have status 94 in DBM_CDR_HEAD.

You might also like