2015
IRI (OSS) Scalability & Accuracy Report
Copyright © 2015 CloudBPO Private Limited All rights reserved
IRI (OSS) Scalability & Accuracy Report 2015
Contents
A.
Scalability .............................................................................................................................................. 4
Scalability with respect to Product features......................................................................................... 4
Scalability with Respect to Data Management ..................................................................................... 6
Scalability with respect to multiple switches support .......................................................................... 9
B.
Accuracy Report .................................................................................................................................. 10
Cost Rule Precision ............................................................................................................................. 10
QoS Precision ...................................................................................................................................... 11
ASR ............................................................................................................................................... 11
ACD ............................................................................................................................................... 11
PDD ............................................................................................................................................... 12
Endpoint blocking/ unblocking accuracy ............................................................................................ 12
Copyright © 2015 CloudBPO Private Limited - All rights reserved
1
IRI (OSS) Scalability & Accuracy Report 2015
Table of Tables
Table 1: Customer Rates ............................................................................................................................. 10
Table 2: Supplier Rate ................................................................................................................................. 10
Table 3: Margin per customer..................................................................................................................... 10
Table 4: ASR data table ............................................................................................................................... 11
Table 5: Call durations ................................................................................................................................ 11
Table 6: Endpoint Blocking data ................................................................................................................. 12
Table 7: Endpoint Unblocking data ............................................................................................................. 12
Copyright © 2015 CloudBPO Private Limited - All rights reserved
2
IRI (OSS) Scalability & Accuracy Report 2015
Table of Figures
Figure 1: MVC Model .................................................................................................................................... 4
Figure 2: Our App structure .......................................................................................................................... 6
Figure 3: Master-Slave topology ................................................................................................................... 7
Figure 4: Query over Distributed nodes........................................................................................................ 8
Figure 5: Master-Master and Master-Slave topology ................................................................................... 8
Copyright © 2015 CloudBPO Private Limited - All rights reserved
3
IRI (OSS) Scalability & Accuracy Report 2015
A. Scalability
IRI-OSS has been developed on java. It is a web based project and we have developed it using SPRING
MVC framework.
The front end has been handled using jquery, jstl, html and jsp while on the back-end we have used
mysql database with Hibernate ORM.
Scalability with respect to Product features
Since it is developed on Spring MVC (Model, View and Controller) so it is very easy to extend the existing
product, we have used Hibernate ORM so we can use any database now.
Figure 1: MVC Model
We have a project having name IRI-OSSService, all the code in this project is independent of any
framework.
We have kept hibernate, email agent code, our cron jobs and rest of the independent things here in this
project. The code can be reused anywhere else as well. In order to integrate the IRI-OSS with any other
database like MS-SQL or may be Oracle. Hibernate configuration needs to be changed and the
parameters will be modified in CONTEXT.PROPERTIES file in IRI-OSSService project.
Copyright © 2015 CloudBPO Private Limited - All rights reserved
4
IRI (OSS) Scalability & Accuracy Report 2015
We have used Object relational mapping ORM Hibernate in our project.
Object Role Modeling (ORM) is a powerful method for designing and querying database models at the
conceptual level, where the application is described in terms easily understood by non-technical users.
In practice, ORM data models often capture more business rules, and are easier to validate and evolve
than data models in other approaches. Some of the advantages of ORM are mentioned below:
1. Facilitates implementing the Domain Model pattern. This one reason supersedes all others. In short
using this pattern means that you model entities based on real business concepts rather than based on
your database structure. ORM tools provide this functionality through mapping between the logical
business model and the physical storage model.
2. Huge reduction in code. ORM tools provide a host of services thereby allowing developers to focus on
the business logic of the application rather than repetitive CRUD (Create Read Update Delete) logic.
3. Changes to the object model are made in one place. One you update your object definitions, the ORM
will automatically use the updated structure for retrievals and updates. There are no SQL Update, Delete
and Insert statements strewn throughout different layers of the application that need modification.
4. Rich query capability. ORM tools provide an object oriented query language. This allows application
developers to focus on the object model and not to have to be concerned with the database structure or
SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the
database.
5. Navigation. You can navigate object relationships transparently. Related objects are automatically
loaded as needed. For example if you load a PO and you want to access it's Customer, you can simply
access PO.Customer and the ORM will take care of loading the data for you without any effort on your
part.
6. Data loads are completely configurable allowing you to load the data appropriate for each scenario.
For example in one scenario you might want to load a list of POs without any of its child / related
objects, while in other scenarios you can specify to load a PO, with all its child Line Items, etc.
7. Concurrency support. Support for multiple users updating the same data simultaneously.
8. Cache management. Entities are cached in memory thereby reducing load on the database.
9. Transaction management and Isolation. All object changes occur scoped to a transaction. The entire
transaction can either be committed or rolled back. Multiple transactions can be active in memory in the
same time, and each transaction changes are isolated form on another.
10. Key Management. Identifiers and surrogate keys are automatically propagated and managed.
Copyright © 2015 CloudBPO Private Limited - All rights reserved
5
IRI (OSS) Scalability & Accuracy Report 2015
Scalability with Respect to Data Management
Currently, we have the database on single machine, we don’t have any Master-Slave strategy, based on
the size of the database and the requirements can change too. May be, we can have a client that would
like to run the IRI-OSS on really huge data set, in order to cater that need, we will have to integrated
things accordingly, based on the strategy of database management and query optimization we might
use Master-Slave topology, CLUSTERING or Master-Master strategy. Our application is very loosely
coupled so it will be really easy to extend the product or modify the existing features because the
database access layer is kept independent and separate.
Figure 2: Our App structure
Copyright © 2015 CloudBPO Private Limited - All rights reserved
6
IRI (OSS) Scalability & Accuracy Report 2015
Right now we have a single server here and the application is deployed along with database.
Depends on the requirements of the client, the database side can change. Most of the clients follow the
basic simple topology know as MASTER- SLAVE topology.
Figure 3: Master-Slave topology
In this topology the data is saved into the slave machine as well, which can be used for read only mode
(may be for reporting) or as a backup.
Master/slave is a model of communication where one device or process has unidirectional control over
one or more other devices. In some systems a master is elected from a group of eligible devices, with
the other devices acting in the role of slaves. In other words "The Master slave configuration is basically
used for load sharing purposes when 2 identical motors connected to two different drives are coupled to
a common load" One drive is defined as the Master and is configured for running in the Speed Control
mode whereas the other defined as Slave is configured for running in Torque control mode.
Similarly, we can use the distributed environment for query optimization or efficient query retrieval. We
can have multiple nodes where the data is kept; the system will perform 2 operations
1) Query the node
2) Merge the results obtained
Copyright © 2015 CloudBPO Private Limited - All rights reserved
7
IRI (OSS) Scalability & Accuracy Report 2015
Figure 4: Query over Distributed nodes
Such strategy is used when the data is really big and query optimization is required. It is dependent on
the requirements of the clients and their usage.
We can have combination of MASTER-MASTER and MASTER- SLAVE topology, where we both the
masters are actually replicating the data and their further share their data with the slaves associated
with them. The below mentioned diagram clearly explains the concept of MASTER-MASTER and
MASTER-SLAVE topology.
Figure 5: Master-Master and Master-Slave topology
Copyright © 2015 CloudBPO Private Limited - All rights reserved
8
IRI (OSS) Scalability & Accuracy Report 2015
Scalability with respect to multiple switches support
We have kept some tables in the database that are playing a very vital role when it comes to switch
integration. All the switches are saved there and can be activated or deactivated via the admin console.
Integration with any switch will need some integration effort, for example, our demo product is
compatible with NEXTONE SWITCH, so we have the client side services of NEXTONE SWITCH, in order to
block customers on Nextone switch we need the web services that can talk to the switch.
Similarly, in order to get the routing information, we are actually talking to the switch database so that
we can get the complete routing information of any pool (we can get everything from the web services,
if and only if your vendor has provided you the details or web services for that particular desired task).
As the system is loosely coupled so it actually provides the support of integration with any number of
switches. The dynamic ADMIN CONSOLE lets you activate or deactivate any switch any time.
The MEDIATION ENGINE is generic, initially in order to integrate a switch, the CDR format template is
created and assigned to a new switch when it is added via admin console. We have the support to
upload accounts, rates and prefix details via IRI-OSS console which will help any office support system to
get integrated with it.
Copyright © 2015 CloudBPO Private Limited - All rights reserved
9
IRI (OSS) Scalability & Accuracy Report 2015
B. Accuracy Report
Cost Rule Precision
Rates in IRI-OSS are being specified up to 4 decimal places. Since most rate sheets from suppliers as well
as rate sheet sent to customers have rates defined up to 4 decimal places, this means that the precision
of IRI-OSS would be 100% when taking rates into account for cost calculations.
The following example illustrates the cost precision:
Suppose there are 4 customers and 2 suppliers with the following rates:
Customer1
Customer2
Customer3
Customer4
0.0175
0.0174
0.0176
0.0175
Table 1: Customer Rates
Supplier
0.0172
Table 2: Supplier Rate
Margin per customer would be:
Customer rate
0.0175
0.0174
0.0176
0.0175
Supplier rate
0.0172
0.0172
0.0172
0.0172
Difference
0.0003
0.0002
0.0004
0.0003
%
1.714285714285714
1.149425287356322
2.272727272727273
1.714285714285714
Table 3: Margin per customer
Gross margin for vendor:
(1.714285714285714+ 1.149425287356322+ 2.272727272727273+
1.714285714285714)/4
=1.712680997163756
=>Where 4 is the number of customers
But since all these calculations will be done in float data type, these calculations will be done as follows:
(1.7142+ 1.1494+ 2.2727+ 1.7142)/4
= 1.712625 ~ 1.7126
This results in an error of= 0.000080997163756
Copyright © 2015 CloudBPO Private Limited - All rights reserved
10
IRI (OSS) Scalability & Accuracy Report 2015
QoS Precision
ASR
The formula for Answer Seizure Ratio (ASR) is:
ASR= Normal calls/ Total calls
Where Total calls = Normal calls + Abandoned calls + Busy calls + Error calls
The following example illustrates the ASR calculation:
Call Status
Abandoned
Busy
Error
Normal
Number of Calls
78
3
27
27
Table 4: ASR data table
In the above scenario, ASR will be:
ASR= (27/135)*100
ASR= 20%
It can be seen that since these numbers will be integers, the precision for ASR would be close to 100%.
ACD
Average Call Duration (ACD) is the average of the call durations for the vendor. The duration of each call
is received in the CDR which is in seconds. This duration is then converted into minutes. The average call
duration is calculated by summation of call durations divided by total number of successful calls.
Suppose there are 4 successful calls for a vendor of the following durations:
Call1
Call2
Call3
Call4
701
501
601
401
Table 5: Call durations
So the ACD for the vendor can be calculated as:
=(701/60+501/60+601/60+401/60)/4
= (11.68333333333333+ 8.35+ 10.01666666666667+
6.683333333333333)/4
= 9.183333333333333
Copyright © 2015 CloudBPO Private Limited - All rights reserved
11
IRI (OSS) Scalability & Accuracy Report 2015
But the rounded off calculations would be:
=(11.6833+ 8.35+ 10.0167+ 6.6833)/4
=9.1833
This results in an error of =0.000008333333333
PDD
Post Dial Delay (PDD) is received in the CDRs. PDD is calculated by summing the PDDs received. Since
this is a simple sum, the precision for PDD would be almost 100%.
Endpoint blocking/ unblocking accuracy (Nextone)
The following numbers were obtained by blocking/ unblocking different number of endpoints.
Overall
Attempt on number of
endpoints
20
40
60
80
200
Number of endpoint
correctly blocked
20
39
60
80
199
% correctly blocked
100
97.5
100
100
99.5
Table 6: Endpoint Blocking data
Overall
Attempt on number of
endpoints
20
40
60
80
200
Number of endpoint
correctly unblocked
20
40
60
80
200
% correctly unblocked
100
100
100
100
100
Table 7: Endpoint Unblocking data
Copyright © 2015 CloudBPO Private Limited - All rights reserved
12
IRI (OSS) Scalability & Accuracy Report 2015
Endpoint blocking/ unblocking accuracy (Mera)
The following numbers were obtained by blocking/ unblocking different number of endpoints.
Overall
Attempt on number of
endpoints
20
40
60
80
200
Number of endpoint
correctly blocked
19
38
58
76
191
% correctly blocked
95
95
96.66
95
95.5
Table8: Endpoint Blocking data
Overall
Attempt on number of
endpoints
20
40
60
80
200
Number of endpoint
correctly unblocked
20
40
59
78
197
% correctly unblocked
100
100
98.33
97.5
98.5
Table 9: Endpoint Unblocking data
Endpoint blocking/ unblocking accuracy (Free Switch)
The following numbers were obtained by blocking/ unblocking different number of endpoints.
Overall
Attempt on number of
endpoints
20
40
60
80
200
Number of endpoint
correctly blocked
20
38
58
77
190
% correctly blocked
100
95
96.67
96.25
95
Table8: Endpoint Blocking data
Overall
Attempt on number of
endpoints
20
40
60
80
200
Number of endpoint
correctly unblocked
20
40
58
77
196
% correctly unblocked
100
100
96.67
96.25
98
Table 9: Endpoint Unblocking data
Copyright © 2015 CloudBPO Private Limited - All rights reserved
13