2013
2013
IRI (OSS) Component Architecture Document
Copyright © 2013 CloudBPO –
All rights reserved
| Context:
1
IRI (OSS) Component Architecture Document
2013
Table of Contents
1. Context: ..................................................................................................................................................... 1
2. Functional View:........................................................................................................................................ 3
2.1 Current Manual Routing System / Task: ............................................................................................. 4
2.2 Post-IRI (OSS) Implementation Automated Activities: ....................................................................... 4
2.3 Post-IRI (OSS) Implementation Manual Activities: ............................................................................. 5
3. IRI (OSS) Process Flow Diagram: ............................................................................................................... 7
3.1 QoS Based Analytics and Re-Routing Process:.................................................................................... 9
3.2 Cost Based Analytics and Re-Routing Process: ................................................................................. 11
3.3 Combined View of QoS and Cost Based Analytics and Re-Routing Process: .................................... 13
3.4 QoS Rules Application Scheme / Process:......................................................................................... 14
4. Constraints .............................................................................................................................................. 16
4.1 User’s perspective ............................................................................................................................. 16
4.2 Developer’s perspective ................................................................................................................... 16
Copyright © 2013 CloudBPO – All rights reserved |
CloudBPO IRI (OSS) Component Architecture Document
2013
1. Context:
In the Telecom industry where Suppliers and Customers interact using an intermediary such as a VOIP
intermediary that connects Suppliers and Customers across the globe. The intermediaries perform the
complex task of connecting the Customers to their desired suppliers by explicitly defining routing and by
keeping in view the quality and cost constraints.
These tasks are traditionally performed manually by NOC and business professionals by corresponding
with each other manually OR via emails. To perform these tasks they need to keep some explicit
business constraints in view as well as the quality of the route provided by different vendors or the
quality of incoming traffic via vendors.
The system in consideration i.e. IRI (OSS) will enable us to automate the complex process pertaining to
the Routing and Re-Routing of the traffic from suppliers to customers. To get this done properly this
system will have following basic components that will help us accomplish Routing / Re-Routing etc.
-
IRI (OSS) Administration, Data management and Reporting Console.
-
Mediation Engine.
-
Routing and Analytics Engine.
-
Intelligent Routing Engine.
Following diagram shows the data and process flow at a higher level among different modules and also
clearly gives and understanding of the different entities that interact with each other.
Copyright © 2013 CloudBPO – All rights reserved
1
IRI (OSS) Component Architecture Document
2013
These components form the baseline of the IRI (OSS) system and allow the correct functioning of the
system. There are other smaller sub-components of the system that allow us to make our system
scalable and allow us to customize the IRI (OSS) as per the varying needs of the users i.e. the internal
users like NOC Engineers as well as account managers. This system allows seamless integration with
various switches like Nextone, VSP etc and has the potential to be integrated with any VOIP switch.
Copyright © 2013 CloudBPO – All rights reserved
2
IRI (OSS) Component Architecture Document
2013
2. Functional View:
Following diagram explains the overall Functional context of the system:
Copyright © 2013 CloudBPO – All rights reserved
3
IRI (OSS) Component Architecture Document
2013
The above diagram clearly shows that in order to keep the day to day operations running there is a
constant need of a bundle of manual set of day to day activities. Above all, another important constraint
is that these activities need to be performed upon intimation or complaints from the customer.
2.1 Current Manual Routing System / Task:
Following are the activities along with the reason for which they need to be performed:
-
Constant Monitoring of Supplier / Customer Statistics:
To ensure that suppliers keep on providing the desired level and quality of service & to ensure
that Customers get the level of service acceptable to them.
-
New Pool Creation:
Creation of new pools to accomplish the newly defined routing jobs as well as to segregate
Customer and suppliers on basis of change expected Quality and Cost parameters.
-
Customer Blocking on Pool due to Violation of QoS / Cost Parameters:
Due to change in offered prices at customer end OR Supplier end resulting in loss due to only
that particular customer we need to perform Customer Blocking. Similarly, due to usage in
excess of available Credit or usage limit may also result in blocking of customer on the Voip
switch totally; however this is usually handled by the Office Support System.
-
Supplier Blocking on Pool due to Violation of QoS / Cost Parameters:
Similarly due to change in cost prices customer end OR Supplier end resulting in loss due to only
that particular supplier, we might need to performs supplier blocking on that pool.
-
Changing the Priority of the Suppliers:
Sometimes we might be required to change the priority of the suppliers based on the fact that
there is a change in quality OR cost offered by that supplier.
-
Changing Priority of Customers:
Sometimes we might be required to change the priority of the Customers based on the fact that
there is a change in desired quality OR margin offered to that customer.
2.2 Post-IRI (OSS) Implementation Automated Activities:
As shown in the diagram above Following are the key points that we need to implement in the proposed
IRI (OSS) solution to make its successful and useful in our operations:
-
Alerts generation in Lieu of Monitoring:
Copyright © 2013 CloudBPO – All rights reserved
4
IRI (OSS) Component Architecture Document
2013
The proposed IRI (OSS) system will be generating alerts based on certain Rules that will
be configured and defined to monitor the system. Therefore, the alerts generation
system will automate the constant Manual Monitoring with a more defined system.
-
Changing Priority of the Suppliers:
This system will also enable us to change the priority of the suppliers once there is an
undesired change in their QoS OR Cost parameters.
-
Changing priority of Customers:
IRI (OSS) will enable us to change their priority as a result of change in desired set of
QoS OR Cost Parameters.
-
Blocking of Supplier on Specific Pools:
IRI (OSS) will also take over the Supplier Blocking over certain Pools when they provided
a degraded traffic. This supplier blocking will ensure that Customers are provided a
desired level of QoS at an affordable cost.
-
Blocking of Customer on Specific Pools:
IRI (OSS) will also take over the Customer Blocking on certain pools if the QoS is getting
affected due to malfunctioning at customer end OR the price offered to Customer is
affecting cost adversely.
2.3 Post-IRI (OSS) Implementation Manual Activities:
-
New Pool Creation:
Initial Pool Creation is an activity that needs to be done first time. These pools will be
created by keeping in mind different business and QoS constraints.
-
IRI (OSS)’s Routing Rules Creation:
This is a panel that will enable the NOC personnel and account managers to create rules
for their customer and suppliers and implement them at Pool level. This Rule creation
activity will serve as a template for applying at different Pools.
-
IRI (OSS) Rules Application Activity:
Copyright © 2013 CloudBPO – All rights reserved
5
IRI (OSS) Component Architecture Document
2013
IRI (OSS) Rules application screen enable users to apply rules on certain pools. A rule
once applied on a pool becomes part of an active Analytics set and Re-Routing is done
when those rules get violated.
-
Manual Actions on Generated Alerts:
IRI (OSS) system will constantly be generating alerts after each analytics cycle based on
the Analysis. These alerts will be pertaining to those rare situations where Rule
Violations occur but no action is defined as a result of violation. Here NOC guys will be
required to take actions in line with the technical and business considerations.
Copyright © 2013 CloudBPO – All rights reserved
6
IRI (OSS) Component Architecture Document
2013
3. IRI (OSS) Process Flow Diagram:
Following diagram depicts the basic process flow for the IRI (OSS) system. This diagram depicts
the flow of data across different entities in the system and processes.
The basic flow for the IRI (OSS) Processing can be defined by the steps given as under:
Step 1:
Copyright © 2013 CloudBPO – All rights reserved
7
IRI (OSS) Component Architecture Document
2013
First input required for the system will be the CDRs that will be transferred from the switches
periodically.
Step 2:
In Second step these CDRs will be processed by the mediator Engine that will parse the CDRs as per the
CDR mapping module and insert the relevant data from the CDRs into our system.
Step 3:
The CDRs data will form the part of basic Seed database required for performing analytics.
Step 4:
Seed Database will also take input from the “Applied Rules” tables and use those rules data to perform
the comparison in the analytics phase.
Step 5:
In next phase the CDR data will be taken in to account to perform the analytics. The Analytics engine will
generate the QoS reports via CDR data on execution.
Step 6:
After Analytics execution, Intelligent Routing Engine will take the Customer / Supplier data pertaining to
rates / Regions as well as the Rules from the seed data base and then compare these results with the
Analytics Results. Upon Execution of The Intelligent Routing Engine, the Analytics Results as well the
Intelligent Routing Rules defined for the Customers / Suppliers will be taken in to account.
Step 7:
After Execution of Intelligent Routing Engine, it will generate a Re-Routing Decision Database / Table
that will be used by Switch Integration Module / Re-Routing Engine to perform Re-Routing Tasks as well
as for generating Alerts.
Copyright © 2013 CloudBPO – All rights reserved
8
IRI (OSS) Component Architecture Document
2013
Step 8:
Finally Switch Integration Module / Re-Routing Engine will perform re-routing on the designated
switches as well as Generate alerts to the admin / NOC user to take necessary action.
3.1 QoS Based Analytics and Re-Routing Process:
Following diagram depicts the basic Analytics and Re-Routing Process as required by the IRI (OSS) system
to perform the QoS based Analytics and Re-Routing:
Copyright © 2013 CloudBPO – All rights reserved
9
IRI (OSS) Component Architecture Document
2013
Following are the steps required for performing the QoS based Analytics resulting in the generation of
QoS Re-Routing recommendations:
Step 1:
Rules will be defined in the Rules database for different routing entities like Dial Code, Regions and Pools
/ Routing stacks etc for Suppliers as well as customers.
Step 2:
Periodic CDRs will be sent to the IRI (OSS) system, where they will be mediated by Mediation Engine and
insert the resultant data in CDRs tables.
Step 3:
Analytics Engine will extract the statistics based on the last period’s CDR data and insert the analytics
results in Analytics database.
Step 4:
This will be followed by Routing and Analytics Module to compare the data sent by CDR with that of the
defined set of rules and detects the anomalies in the system i.e. those statistics that violate QoS rules
and generate QoS based Routing Anomalies.
Step 5:
The Analytics Modules results will then be processed by Intelligent Routing Engine and the engine will
use these Results to generate the Re-Routing Job. These jobs will then be used to perform the Actual reRouting.
Step 6:
The jobs placed by Analytics module will then be followed by Re-Routing Process / Switch Integration
Module, to perform the Re-Routing on the designated switches.
Copyright © 2013 CloudBPO – All rights reserved
10
IRI (OSS) Component Architecture Document
2013
3.2 Cost Based Analytics and Re-Routing Process:
Following diagram depicts the basic process for Cost based Analytics and Re-Routing as proposed for the
IRI (OSS) system, it is important to note here that in order to perform the cost based Routing we do not
need to execute mediation by processing CDRs, rather we just need to have the Cost and Tariff data for
Suppliers and Customers only:
Following are the steps required for performing the Cost based Analytics resulting in the generation of
Cost Based Re-Routing recommendations:
Step 1:
Suppliers Cost as well as Customer Tariffs is read by the IRI (OSS) system’s Routing and Analytics
Module.
Copyright © 2013 CloudBPO – All rights reserved
11
IRI (OSS) Component Architecture Document
2013
Step 2:
These Costs will then be used by Routing and Analytics Module to generate the violations in Cost and
Tariff by comparing them with the defined set of Rules. Routing and Analytics Module will then forward
all the violations to the Intelligent Routing Engine.
Step 3:
The Routing and Analytics Engine will the generate the alternate Routing by comparing the Violations
and mapping them on the Re-Routing principles embedded in to the system OR will generate Alerts for
the visible Anomalies so that they can be entertained by the NOC personnel manually.
Step 4:
Re-Routing Process OR Switch integration Module will then use the designated Re-Routing jobs and
enforce the Switch to change the Routing accordingly using http Calls exposed by the switch.
Copyright © 2013 CloudBPO – All rights reserved
12
IRI (OSS) Component Architecture Document
2013
3.3 Combined View of QoS and Cost Based Analytics and Re-Routing Process:
Following is the diagram that depicts the QoS and Cost based routing in a combined fashion as these
Analytics and Re-Routing Processes usually work in pairs and supplement each other with their Results:
Following text gives a high level interaction of both types of Analytics and Re-Routing Results:
Step 1:
The Analytics Generated by QoS and Cost data will be generated in analytics cycle.
Step 2:
These Analytics will then be compared with the QoS and Cost Rules for both the type of Rules available
in the system i.e. QoS and Cost Rules.
Copyright © 2013 CloudBPO – All rights reserved
13
IRI (OSS) Component Architecture Document
2013
Step 3:
For those entities where there will be a definite violation in Cost Parameters, Intelligent Routing Engine
will generate Re-Routing Requests that enables us to Block Customer / Suppliers on a certain pool OR
allows us to change the priority of Customer / Suppliers.
On the other hand if there is only a violation in QoS parameters then there will only be change in priority
of Suppliers / Customers OR Alerts generation by the system.
Step 4:
RE-Routing Engine / Switch Integration Module will then proceed further to execute the Re-Routing
request on the target switches OR generate alerts to the Account Manager / NOC personnel for the
analyzed Violation:
3.4 QoS Rules Application Scheme / Process:
Following diagram displays a high level QoS Rule Application Process that we can apply on the active
routable Entities present on the switch.
As per this diagram following are the level of entities where certain QoS rules can be applied:
-
Suppliers.
-
Countries / Dial codes.
-
Routing Stacks / Pools. ( Currently Available and implemented)
-
Routes.
As per this scheme once a rule is applied at certain level it will become a parent verification entity for all
the Childs and will be verified for violation before any Re-Routing job is actually placed. If violation still
exists there will be a Re-Routing Job that will be placed, otherwise only a plain alert will be generated.
This Rule application scheme will enable the system to ensure that routing doesn’t get change randomly
or frequently due to very minute changes at the end of customers OR suppliers caused due to random
Copyright © 2013 CloudBPO – All rights reserved
14
IRI (OSS) Component Architecture Document
2013
human behaviors. Therefore, this scheme will ensure that routing changes only take place when there is
a definite problem that can be verified by checking the similar data set at higher levels.
Copyright © 2013 CloudBPO – All rights reserved
15
IRI (OSS) Component Architecture Document
2013
4. Constraints
As far as the local standards are concerned, we are developing it using the Model, View and Controller
approach so the source code is very organized and can be re-used easily. We have separate layers for
services and Data Access Object. We have been following the basic standards while coding.
We are using Web-Services (SOAP based) to communicate our messages to the switch. We have written
the client and the server is on switch side. We send our messages via our client services.
4.1 User’s perspective
Software constraints:
Internet browser to access application
Hardware constraints:
Dedicated IRI (OSS) Application and Database Server.
A suitable internet connection
A suitable environment to manage the temperature of the running machine
4.2 Developer’s perspective
Software Constraints:
JRE and Jdk
MySQL database
A web server ( we are using apache tomcat)
Any MySQL client to access database
IDE (we are using Eclipse INDIGO)
Hardware constraints:
A Sever with a high end configuration to support complex calculations.
Machine to maintain the temperature of the servers
Copyright © 2013 CloudBPO – All rights reserved
16
