2014
PROOF OF CONCEPT
Copyright © 2014 CloudBPO –
All rights reserved
IRI (OSS) POC
2014
The IRI Concept and POC
The basic idea for the IRI module is to intelligently route the customer’s traffic based on combination of
Quality and Cost of the different routes configured and available in the system. The system will follow
the following flow in the application:
a. Switches will periodically FTP CDRs to the Server hosting IRI.
b. The mediation Engine on the IRI server will parse CDRs and perform validation on these CDRs and
will insert the CDRs in the system.
c. The System users will login to the IRI’s console and define the Rules pertaining to QoS and cost for
each customer.
d. The Rules for each customer could be configured distinctly for different Routes/ Regions and
should be editable and Override-able.
e. After insertion of CDRs into the system, there will be an Analytics engine that will perform
different Queries on the inserted records and retrieve the customer / vendor wise statistics
pertaining to Cost and Quality.
f. After Analytics Engine has analyzed different Customer Routes in terms of Cost and Quality it will
compare the gathered statistics with the Rules available on the IRI portal.
g. If the analyzed data doesn’t violate the Rules defined in the IRI module for different set of
customers, the route details will remain untouched and no changes will be proposed /
implemented.
h. If the analyzed data violates the Rules defined in the IRI module for different customer, the
Intelligent Routing Engine will come into play and will perform certain activities after observing
the Routes during next Analytic Cycle.
1. Management Console
IRI admin console will be the basic console where the admin user will configure the basic execution
rules for execution of IRI modules. The main components of this module will be as under:
a.
b.
c.
d.
e.
f.
Switch Details panel
CDR mapping Module
Console for FTP Settings Switches
CDR Mediation Configuration
IRI Configuration Console for Switch
Analytics configuration module (E.g. Enabling disabling Switch parameters)
In the current demo we have developed the basic screens to show the basic operations that
will be supported by IRI.
Copyright © 2014 CloudBPO – All rights reserved
2
IRI (OSS) POC
2014

Add rules
o QOS (quality based rules)
o Cost Based Rules
 View rules screen
 Apply Rules
 Un-apply Rules
 View Routing of a particular pool
 View Report
o Cost report
o QoS based report.
Once the system features are developed, the additional modules will be
i. Access management
ii. Dynamic engine to support N switch (basically X- Mediator, where x will be the CDR of
any switch)
iii. Additional features such as email recovery, user account creation, and basic security
features, etc.
Add / View Rule Screens:
There will be a screen that will enable users to add the rules, view and filter them inside a grid, a
brief overview of adding rules and Viewing Rules is as under:
Adding Rule Screen:
The IRI System Administrators and users need to define certain set of “Rule Templates” that could
be applied to certain Vendors, Regions, dial codes and Routing Stacks. These Templates will enable
users to define a Rule that comprise of multiple QoS and Cost parameters that are grouped under
single header. User may choose to apply Boolean “AND” and “OR” logic to different parameters to
ensure the integrity and compliance to multiple rules at one time. An example of this template can
be demonstrated by scenario below:
Copyright © 2014 CloudBPO – All rights reserved
3
IRI (OSS) POC
2014
Sample Rule Scenario:
A sample rule can be as under:
1.
The ACD (Average Call Duration) should be Greater than 5 Minutes and Less than 25 minutes
2. The ASR (Answer Seizure Ratio) should be greater than 35
OR
The NER (Network Effectiveness Ratio) should be greater than 25
3. Cost should be less than 0.025
4.
This Rule will be inserted in system as Template as per the following logic:
Rule XXY:
- [ACD > 5 Minutes.
AND
ACD < 25 Minutes]
OR
- [ASR > 35 Minutes
OR
NER > 25 Minutes]
OR
- [Cost < 0.0025 USD]
The above Rule forms a Template and can be added against different Vendor, Specific Country Codes,
Dial Codes as well as Pools.
These templates will make it easier to bind this rule on multiple data parameters mentioned above and
user will not have to separately select different parameters and create and apply rules to them. The
sample UI that can be used to defined Template is shown as under:
Copyright © 2014 CloudBPO – All rights reserved
4
IRI (OSS) POC
2014
Rules Dashboard:
Rules Templates Dashboard will be a dashboard that will be used to list different Rules available in the
system and will allow users to Filter and Search Rules on basis of following categories:
A.
Rule Names.
B.
Rule Types.
User will be able to search Rules on this Dashboard as well as add and Delete Rules.
However, if a Rule has already been associated to any of the entities like Vendor, Country / Dial codes,
pools OR Routes, then the system should not allow users to delete the rule.
Rules Application Screen:
Rules application screen will be a screen that will allow the system admin and users to map these rules
with the different system entities like Vendor, Country Code / Dial Code, pools as well as routes. Using
Copyright © 2014 CloudBPO – All rights reserved
5
IRI (OSS) POC
2014
this screen user can select the entities for which he wants to apply rule in a hierarchal manner. The
hierarchy that governs the selection of entities is as under:
Vendors → Country Codes / Dial Codes → Pool / Routing Stacks → Routes.
Therefore, this screen enables users to apply their rules on any specific level entity i.e. a system user
may choose to apply a certain rule only on a Vendor without taking into consideration micro level
parameters pertaining to that vendors like Vendor’s provided dial codes OR Routing stacks etc.
On the other hand a user may choose to enable and apply rules pertaining to vendors coupled with their
dial codes and routing stacks. Therefore, this screen provides flexibility to apply rules at multiple levels,
and enable users to design the rules that enables system to make efficient decision making. A basic
interface for this screen is shown as under:
Copyright © 2014 CloudBPO – All rights reserved
6
IRI (OSS) POC
2014
Viewing Applied Rules:
The user may be required to edit the rules that have been added for certain vendors, dial codes as well
for Routing Stacks. Therefore, user may be required to view and Edit certain rules. The “View Rules
Screen” will enable users to view all the Rules that have been applied against certain suppliers, dial
codes as well as pools. This screen will enable users to filter the applied set of Rules using following
Filters:
→Rule Name.
→Supplier.
→Dial Code. (Using Wild Cards)
→ Routing Stacks
→ Association Date.
→ Modification Date.
A working sample of Rules application screen is as under.
2. Mediation Engine:
Mediation engine is the module that will extract information from the Raw CDRs and store in the
relevant database for further processing. This engine validates CDRs and dumps them in the customer
database after they pass validation. All the CDR files provided to the Mediator engine require to be
Copyright © 2014 CloudBPO – All rights reserved
7
IRI (OSS) POC
2014
named in a specific format for proper validation. A comprehensive overview of Mediation Engine can
be found in the following sections:
Mediation Process Details:
Mediation process used for inserting CDR records from File into database for further Processing will
work as under:
a. All CDRs will be sent from Switches to Machine Hosting Mediation Engine periodically (after
every 5 minutes) in specific name format compressed in tar.gz.
b. Mediation Engine will Run periodically, every 10 minutes and perform processing on the
available CDR files
c. Mediation Engine will read each file Row by Row and insert the relevant record in the CDRs
database.
d. If a certain file or Record in the file fails validation NO record will be inserted in the CDRs table
and a single alert will be generated for the corrupt file.
e. If all the CDRs in a file pass the validation criteria they will be inserted in the system’s CDRs table
and transaction will be committed to the once a file has been parsed completely.
Mediation Process Architectural Design:
Mediation Process architecturally comprises for following 3 stages:
i. FTP module on the Switch:
This module will be used to FTP CDRs periodically from switch to the Server hosting IRI. It will
collect CDRs every period (ideally 10 minutes) and will FTP these CDRs to a specific location at
IRI server, from where Mediator will process the File.
ii. Mediator Process:
Mediation Process will parse the file and validate the CDRs, if file as well as individual CDRs
pass the CDR validation, the same job will copy the CDR data from file to CDRs table.
iii. CDRs Database:
CDRs will be inserted into CDR’s partition table that will host all the CDRs. These CDRs will be
used to perform analysis using “Routing and Analytics Engine”.
Copyright © 2014 CloudBPO – All rights reserved
8
IRI (OSS) POC
2014
Mediation Process Database Design:
Mediator database will comprise of majorly 2 CDR tables. The description of these tables is given as
under:
i. CDRs Table.
ii. The CDR-Analytics table.
CDRs Table: The CDRs table will be used to record all the transactions pertaining to a switch. All the
data fetched from a customer will be dumped in this partition table.
The CDR-Analytics Table: The CDR analytics table will be a table that will be populated only at the
time mediation and before of execution of Reporting at Analytics Engine. This table will be flushed
as soon as Fresh Analytics cycle gets completed.
Mediation Process Limitations:
Following are some of the Limitations that are applicable on mediation process:
i. Mediation process will be periodically working to input CDRs data into the system, however due
to drastically huge number of columns in a CDR and variable format of CDRs that are being sent
from the Switch to IRI module, therefore performing validation on each and every field is not
viable. Therefore, mediation process will simply insert the sent CDR in the format required by
switch as defined in the “CDR Mapping Console”.
ii. It will not perform Field level validation and will work only on the sequence of insertion of the
column as provided by the “CDR Mapping Module” blindly.
Copyright © 2014 CloudBPO – All rights reserved
9
IRI (OSS) POC
2014
3. Functioning of Analytical Engine and Intelligent Engine:
In order for the IRI system to function properly, we need to gather statistics pertaining to
different quality and cost parameters pertaining to the Suppliers and compare them with those
that are desired for certain suppliers, their corresponding statistics in Groups, regions and dial
codes governed by a certain set of “Rules/Constraints”.
Therefore, ideally the flow of the Analytics Engine to perform the analysis will be as shown
in the diagram below.
Copyright © 2014 CloudBPO – All rights reserved
10
IRI (OSS) POC
2014
Analytics and Reporting Engine Reports:
Analytics and Reporting Engine Reports will primarily work on 2 set of parameters, these parameters are
as under:
1. Rules Database.
2. Analytics Database.
More importantly, the output of the QoS analytics and reporting will be in form of 2 basic types of
reports analytics as mentioned below:
1. QoS Analytics and Reports.
Copyright © 2014 CloudBPO – All rights reserved
11
IRI (OSS) POC
2014
2. Financial Analytics and Reports.
NOTE: It is important to mention here that we need to not only calculate these statistics for each vendor
on whole but also to compute these statistics for each of these vendors for all his active Country Codes
and Dial Codes. This will be a very critical set of details as it can help system in determining and pin
pointing the exact thing causing trouble.
The base line information provided by these reports can be bifurcated into following types of statistics
that will enable the system to intelligently rout the Traffic.
Problematic Routes: “The Analytics and Reporting Engine Reports” will highlight all the Vendors,
Country Code’s / Dial Codes as well as Routing Stacks that are experiencing either deteriorated
performance OR have issues pertaining to Costs and quality.
Running Statistics: This Engine will compare the running statistics of all the vendors on basis of with
different Rules available in the Rules database and give its recommendation with respect to routing AND
/ OR blocking of the Routes.
Re-Routing Recommendations and Jobs: These analytics and respective recommendations will be saved
in the system for action at a later stage based on the threshold defined for wait time.
Wait Time: A “Wait Time” will be applicable on the analytics recommendation that will give system an
option to re-analyze the routing statistics before the re-routing job is actually executed.
Following sections show certain type of QoS and Cost based Analytics and Reports that need to be
incorporated in the system.
Below mentioned screens show the basic cost based and Qos based reports that are generated and
helpful to understand the workflow of IRI.
Copyright © 2014 CloudBPO – All rights reserved
12
IRI (OSS) POC
2014
Call connectivity measure enable us to determine the statistics for a vendor in terms of calls made and
the calls that were successfully connected to the destination. These set of inputs help in measuring the
Connectivity standards of a Vendor. Following are some Measures we are going to take into account
while considering “Call Connectivity”:
a. Answer Seizure Ratio (ASR).
b. Average Call Duration (ACD).
c. Post Dial Delay (PDD).
A brief description of each of the above mentioned statics is shown as under:
ANSWER SEIZURE RATIO (ASR):
ASR stands for “Answer Seizure Ratio” and is the ratio of Total number of calls answered vs. Total
number of calls attempted. Total calls include calls that were abandoned, had busy response OR were
rejected.
Copyright © 2014 CloudBPO – All rights reserved
13
IRI (OSS) POC
2014
ASR report per Vendor per Country Code / Dial Code:
Vendors / Supplier are the primary entity in the system that provide the EGRESS traffic routes and their
QoS and cost statistics are of supreme importance when it comes to basing the re-routing decisions.
This is a primary report that will enable the system to actually take the rerouting decision if a Vendor’s
ASR is falling beyond a certain ratio. This report will provide the statistics pertaining to specific Vendor
and provides statistics for all his dial codes. All the statistics where ASR is falling beyond a certain
threshold will be considered by IRE (Internal Routing Engine) based on certain IRE rules to decide and
actually perform re-routing.
Average Call Duration (ACD)
Average call duration is the measure of Average Length of a call that is based on a call record and is used
to determine and forecast the demand and is used for monitoring of the Telecom infrastructure and
Traffic. A Simple Formula for ACD is as under:
ACD = Sum of Duration of Answered Calls
Total Calls
ACD report per vendor:
Each Vendor has some “Time of Day” benchmarks for Average Call Duration of his traffic pertaining to
certain Country Codes / Dial codes. These bench marks are usually defined in the IRI Rules Module and
are then compared with the Running statistics provided by Analytics Engine.
ACD Report will be a report that will contain “Time of Day” benchmarks for each and every Country
Code / Dial Code pertaining to a Vendor. These Bench marks will then be used to compare with the
Rules that are applicable for that customer for those Country Codes / Dial Codes. If the Rules are getting
violated, then the country codes/ dial codes for which these Rules were violated will be highlighted
appropriately using a separate flag. All the statistics with these problems will be considered by IRE
(Internal Routing Engine) based on certain IRE rules to decide and actually perform re-routing.
Copyright © 2014 CloudBPO – All rights reserved
14
IRI (OSS) POC
2014
Post Dial Delay (PDD):
Post Dial Delay is the interval when the caller presses the Dial button on the phone and when the Phone
starts ringing OR Busy Tone is heard from the other side.
PDD ideally should be of very minimal length and Greater the PDD is lesser is the quality of the call.
Therefore, it is very important to minimize the post dial delay for any Telephony Network and any
discrepancies in the network should be adequately taken care of.
Post Dial delay depends on a variety of factors pertaining to a telephony network but the prime factor
that affects Post Dial delay is the number of nodes involved.
Copyright © 2014 CloudBPO – All rights reserved
15
IRI (OSS) POC
2014
PDD Report per Vendor:
Post Dial Delay report for each vendor needs to be run with respect to all the country codes / dial codes
for which that vendor provides traffic. For a vendor to be efficient the Post dial Delay should be minimal
and call should connect without significant delay.
The statistics gathered by this report will be compared with the benchmarks defined in the IRI and then
if the rules are getting violated, then the country codes / dial codes for which these rules were violated
will be highlighted using a separate flag. All the statistics with higher PDD will be considered by IRE
(Internal Routing Engine) based on certain IRE rules to decide and actually perform re-routing.
3. Routing Engine
The analytical and intelligent engines will be dependent on one another. The analytical engine will
basically help intelligent engine to generate the statistics and based on the generated statistics the
intelligent engine will generate routing decisions. The function of Routing engine will be just to
modify the routing; it is basically dependent on the output of intelligent engine and performs routing.
There is no SCREEN where you can view how it is being done but there is a screen where you can see
the routing of a particular pool once the INTELLIGENT ENGINE is done with its job.
Copyright © 2014 CloudBPO – All rights reserved
16