KENAN

Kenan / BP is a high level billing software which is widely used for usage based products
and customer care like telephony, internet access, dish antennas etc.

Service instance: It is the service delivery point in a network. Service instance does not
represent the service or the product itself, but it represents the mechanism through which
the product or service is provisioned to the customer.

BLOCK DIAGRAM DESCRIPTIION:

The Kenan / BP system has 2 basic parts:

1. OM – order management
2. BP – Bill production

The system has an external id which is you mobile number and the kenan system
generates an internal id which is the account number.

The Kenan system has 3 major databases:

1. Catalog
2. Admin
3. Customer

The Kenan system supports the Multi Server Architecture (MSA). So there is 1 catalog
database, 1 admin database and n number of customer databases.

Initially there was the Single Server Architecture (SSA), which had only 1 server
containing all the 3 databases together.

The properties of each server are stored in a table called SERVER_DEFINITION. It

contains the server type as follows
1. Catalog
2. Admin
3. Customer.
It also contains the server id, which needs a value greater than 0. It also contains the
server’s IP address.

1. Catalog

This database contains the server information like the server’s IP address, server id,
number of accounts etc.
 The main function of this database is load balancing. This means that when an
account is created it needs to be updated or entered into the database. So the catalog
database checks with each server to see if there is space available for another account
to be stored in it. If yes the entry is made else it moves on to the next server to check
for space availability. So basically the catalog server does not allow the overloading
of any server.

The tables associated are:

1. SERVER_DEFINITION
2. SERVER_LOOKUP:
This table is used when you need to find out which account is placed in which server.
So you give the account number in this table and it returns the server id.

2. Admin:
This database contains static data, which is the data to be configured. It contains the
package and component related information.

3. Customer
This database contains all the information related to the customer. It contains
customer account numbers, number of customers, the billing, usage and rating
information.

1. OM

Order management basically creates and modifies the services of an account but it can
never delete an account.

When a customer needs a new account to be created, the customer fills the (CAF) that is
Customer Account Form available with the Customer Service Representative (CSR). The
CSR’s then pass the orders through the GUI to OM. The OM then routes the respective
services to the customers.
The services provisioned to the customers like SMS, VOICE etc are called switches. So
the switches are activated by the OM upon receiving orders through GUI by the CSR.

OM follows a workflow. The execution of task is workflow. In OM when a work is to be

done it does all the tasks, but the last task in the workflow would be the update done by
ARBOR_UPDATOR. The ARBOR_UPDATOR replicates the account details into BP
and also updates the tables. This is done so that BP can start rating and billing for that
particular account.
 2. BP

The Message Processing System (MPS) calculates the usage charges for the Arbor /
BP customers.

The following are the processes in MPS.

1. COM – communication process

2. MCAP – usage router
3. CAP – usage guider and rater
4. BIP – bill preparer
5. BIF – bill formatter

PROCESS SCHEDULE

Before any process that’s carried out in the kenan system or in BP requires an entry to be
made in the table – PROCESS_SCHED. Else the process is not considered to be valid.

1.COM
When a call is made, a number of Cal Detail Records (CDR’s) are generated for that call.
These files are stored in the switch. The switch contains a lot of junk CDR’S.

 The switch transfers the files to the Data Mediation (DM) trough batch
processing. Batch processing is done to transfer the files from the switch to the
DM at regular intervals. So it basically picks the files and places them in DM.

 The DM now has received a lot of junk CDR”S. the basic function of the DM is to
filter the junk CDR’s and make a useful CDR, ready to be rated.
Table: TYPE_ID_USG: This table defines the nature of the call. Whether it is an
international or a local or an STD calls. It also gives the point origin and point target of
the call made.

The DM attaches a TYPE_ID_USG tag with every received CDR and sends it to the
Remote Directory. The remote directory resides in the admin database.

Now the records are in the remote directory.

This is where the actual COM process comes into picture.

 There are 4 local directories and 3 remote directories:

The remote directories are controlled by the external systems such as credit card clearing
houses and network usage products like Internet etc, and BP controls the local directories.

Remote directories:
1. WORK
2. READY
 3. DONE

Local directories:
1. WORK
2. READY
3. DONE
4. ERROR

The basic function of the COM process is to transfer the files from Remote directory into
BP.

 Before COM starts to pick the usage files from remote directory, an entry needs to
made in the process schedule table as follows:

PROCESS_SCHEDULE:

$COM COM01 EXT_CONATCTS EXT_CONTACT_ID=’00000’

where
COM – is the process name
COM01 – is the process name with the sequence number
SEQ_NUM – every process that’s carried out in the Kenan / BP system is assigned a
unique sequence number. Like COM01, COM02, COM03 etc .

 So COM has to retrieve files from remote directory.

1. When the files come from the data mediation, they are in the remote WORK
directory. That’s the mid stage.
2. When the files are in the remote READY directory, it means that the files are
ready to be picked by COM. COM picks the files that are prefixed with USG. For
eg USG------------------, some number.
3. Once COM picks the files, the original file is moved from ready directory to
DONE directory in the remote directory. This is to indicate to the external contact
that COM has picked the file and also prevents Com from retrieving the same
files.
4. Once COM picks the files from the ready remote directory, it places the file
prefixed with USG in the local working directory.
5. From there, COM moves the files to local ready directory and at the same time in
the local done directory.
6. In case the file has some sort of an error, then the file is put into the local error
directory.
7. Once the file has reached the local ready directory, it means that the file is ready
to be picked by MCAP and routed for rating.
  In the remote directory there is table called the EXT_LOCAL_DIR_ACCESS
which generates a unique EXTERNAL_CONTACT_ID. The EXT_CONTACTS
table in local directory also has the EXT_CONTACT_ID. Com uses this unique
external id to fetch the appropriate files.

So the directory work practically happens before the MPS process can actually begin.

 Once COM picks up the files, COM put an entry into the FILE_STATUS table.
This table gives a unique FILE_ID for every file entry that’s made into it. COM
renames the files and puts them into the file status table as
100.USG------------.01.456 where,

- 100 – EXTERNAL_CONTACT_ID – It gives the region from where the call is made.
Every circle has a unique contact_id.
- 01 – the server_id
- 456 – unique file_id.

 MCAP – Usage router

The basic function of the MCAP is to guide and rate the usage events.
MCAP runs in the admin database.

1. Before MCAP begins to carry out the processes, entry into the process schedule
table is made as follows

PROCESS_SCHED :

$MCAP MCAP01 FILE_STATUS FILE_ID=’00000’.

2. Once the files are picked from the FILE_STATUS table, MCAP parses each
record in the file.
It then checks the format of each record as specified in the
RAW_USAGE_FIELD_MAPPING table. The records can be parsed in one of the
following ways:
a) the first 3 characters in the record.
b) The header and the trailor records.

The files could be rejected for one of the following reasons:

a) Unknown record type
b) Unknown data types
c) Record size
d) Header and Trailor records.
e) Record miscount.
 3. MCAP also checks for duplicate records by checking the point target and point
origin and call duration for each call, which is unique for each call which is
obtained by the TYPE_ID_USG table.

4. Once the records are parsed and the format is checked and also duplicate records
are checked, MCAP puts an entry into FILE_STATUS table.
10 ,4– Files processed successfully
6 – file processing failed.

 REPSTAT

MCAP runs in the admin database while CAP runs in the customer database. Hence the
records from the admin database needs to be transferred into the customer database which
is done by the RepStat process.

RepStat basically replicates the FILE_STATUS table from the admin database into the
customer database.

There are 2 modes in which a RepStat can run:

1. RepStat UPDATE: where only the latest records are updated
without any duplication and it is faster.
2. RepStat ALL: where all the records are updated even with
duplication and it takes away a lot of time.

 CAP – usage guider and rater:

Once the FILE_STATUS table has been replicated in the customer database, it is ready to be
rated.

Cap basically guides, rates and stores the usage files that are routed to the customer database
by MCAP.

1. Before the CAP process begins, entry is made into the process schedule table as
follows:
PROCESS_SCHED:

$CAP CAP01 FILE_STATUS FILE_ID=’00000’ 01

Where
01 – is the server number or server id. Since CAP runs in the customer database, it needs the
server number where the account resides.

2. For each record CAP verifies the data, guides the record to an account and rates the
record.
 3. The rated records are then populated into 4 modules by CAP

a) CDR_DATA – This field contains any record that is ready to be billed.

b) CDR_FREE – This field contains the records which are not meant to be billed at all
like tollfree calls, police, ambulance, fire service etc.
c) CDR_OUTCOLLECTS – this filed contains records of roaming calls.
d) CDR_DATA_WORK – This field contains the records with errors. These errorred
records are sent to the Message Investigation Unit (MIU). MIU reviews the errors,
corrects them and puts them into CDR_DATA.
MIU can run in 2 modes namely
1. Batch mode: where the records are corrected in batches, as it is faster.
2. Single record mode: only one record at a time.

4. CAP then updates the FILE_STATUS table.

10– success and 6 – failure.

a) BIP – Bill preparer:

BIP determines which customers need to be billed. Then it collects and calculates the
charges, discounts, taxes and so on and prepares an unformatted bill based on that
information. BIP runs in the customer server.

1. Before BIP begins to bill an entry is made into the process schedule table as follows:

PROCESS_SCHED:
$BIP BIP01 CMF ACCOUNT_NO=’00000’ 0,6,3

Where CMF is the table that gives the unique account number for that particular customer to
be billed.

2. BIP collects the rated records from the CDR_DATA. BIP basically acts as a calculator. It
just sums up all the rates.

3. The main tables associated with BIP are:

a) BILL_INVOICE – mapping between the account number and the invoice number.
Each record basically summarizes an invoice.
b) BILL_INVOICE_DETAIL – It gives the description of the bill, like what are the
monthly rentals. It contains the package id and the component id.
 c) BILL_EQUIP_DETAIL – Gives the information of each and every call that is
made.
This is a dynamic process where in the values are populated automatically.

4. BIP can run in 4 modes namely

a) Inter Rim – The bill is processed when the threshold is exceeded. Basically when
a customer gets an account from a company, a certain maximum limit is set. Once
the limit of the amount is exceeded, the bill is processed and the customer is asked
to make an immediate payment in the middle of the month.

b) 0Production – the final bill

c) 3Pro forma – the testing bill. To check if all the values are right.

d) 6Back out – reverses all the transactions that were being processed to generate
the bill being backed out.

0 – production 3 – pro forma 6 – back out

5. BILL_CYCLE – Entries into this table is mandatory as this table defines the dates and
cycles when the bill needs to be prepared, formatted and dispatched.

 BIF – bill formatter

BIF runs in the customer server.

1. Before it formats the bill, an entry is made into the process schedule as follows:

PROCESS_SCHED:

$BIF BIF01 BILL_INVOICE BILL_REF_NUM=’00000’

2. BIF reads the unformatted invoice record written by BIP and prepares a formatted
invoice.

- about the 3 remote and 4 local directories.

With regards to Q2, Basically there are directories both

internal to Kenan i.e. these directories are local, meaning
those that are accessible only by Kenan and not by any
third parties. These directories are defined in the table
EXT_CONTACTS. However, the files are placed in
directories that are remote/external to Kenan by the
Mediation. These directories are defined in the table
EXT_LOCAL_DIR_ACCESS. These need to be brought into
the Kenan system i.e. to the local directory so that rating
and billing can be done. COM is the process that moves the
files from the external directories to the local directories.

- Why package is not provisioned to service

instance level and why only to account level?

With regards to Q1, as a thumb rule package

always is attached to the account. Package is
basically configured for ease of provisioning. It
can have components that can be either account
level/service level. For eg, when you configure
discount at the account level it means that when
you provision it to an account having many
services the discount applies to all it's
associated services. But when you do the same
at the service level it applies only to the specific
service to which the discount is attached.

What's the difference between account level and service instance level?
Account level means say for example, a customer has a mobile connection, internet
connection and dish TV for a single account, if u provision any component to him and
assign it as account level then the component will get attached to all the Service
instances(mobile,internet,dishtv), so if u want to restrict it to say mobile, then u have
to provision it for service instance of mobile only.