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