LRC 2.1 / LTW 4.1 Technical Product Description

(1)

LRC 2.1 / LTW 4.1

(2)

Copyright

© THE CONTENTS OF THIS DOCUMENT ARE THE COPYRIGHT OF LAVASTORM TECHNOLOGIES. ALL RIGHTS RESERVED. THIS DOCUMENT OR PARTS THEREOF MAY NOT BE REPRODUCED IN ANY FORM WITHOUT THE WRITTEN PERMISSION OF LAVASTORM TECHNOLOGIES.

Disclaimer

No representation, warranty or understanding is made or given by this document or the information contained within it and no representation is made that the information contained in this document is complete, up to date or accurate. In no event shall Lavastorm be liable for incidental or consequential damages in connection with, or arising from its use, whether Lavastorm was made aware of the probability of such loss arising or not.

(3)

Contents

1.0 Introduction ... 4

2.0 General System Architecture ... 4

2.1 Back-End Server Environment ... 5

2.2 Application Server ... 5 2.2.1 Application Server ... 5 2.2.2 Report Server ... 5 2.3 User Interfaces ... 5 2.3.1 Web Application ... 5 2.3.2 Administrative Client ... 6 3.0 System Functionality ... 6

3.1 Data Capture and Readers ... 6

3.1.1 Data Capture ... 6 3.1.2 Readers ... 6 3.2 Enrichment Modules ... 7 3.3 Aggregation ... 8 3.4 Alarm Setup ... 9 3.4.1 Aggregate Alarms ... 9 3.4.2 Scanning Alarms ... 9

3.4.3 SQL Data Source Alarms ... 9

3.5 Logistics ... 10

3.6 User Administration ... 10

3.7 Workflow for Case Management ... 11

3.8 Data Sources & Data Types ... 12

3.9 Context Sensitive Menu ... 12

3.10 Hotlist Functionality ... 13

3.11 Reference Data ... 13

3.12 Suspect Types ... 14

3.13 Alarm Manager & Routing Engine ... 15

3.14 Explorer & Permissions ... 16

3.15 Query Builder ... 16 3.16 Ad-Hoc Visualization ... 17 3.17 Report Publishing ... 18 4.0 Technical Requirements ... 19 4.1 Client Platform ... 19 4.1.1 LRC Web Client ... 19 4.1.2 LTW Administrative Client ... 19 4.2 Server Platform ... 19

(4)

4.2.1 Hardware ... 19

4.2.2 Minimum Sizing ... 19

4.3 Software Support ... 20

5.0 System Capacity & Configuration ... 20

5.1 General Considerations ... 20

5.2 Hardware Resources ... 20

5.3 Data Storage ... 21

5.4 Scalability ... 21

(5)

1.0

Introduction

This document describes the general aspects of the Lavastorm Resolution Center (LRC) 2.1 and the Lavastorm Transaction Warehouse (LTW) 4.1. It covers the basic architecture and provides an overview over major features. The document also contains a section on technical requirements related to supported platforms and third party software, as well as a discussion on system capacity, general performance and basic hardware considerations.

2.0

General System Architecture

The LRC and LTW are two independent products. LTW provides the key functionality to gather, normalize, enrich, and aggregate data, and LRC provides the capabilities for alarming, case management and reporting. The features from each of the two products can be used separately without any direct use of the features of the other product. Though, in the LRC 2.1 / LTW 4.1 release some of the back-end architecture is non-separable and the two products must be deployed in a combined solution. Appendix A contains a detailed list of all system parts, where it is noted which product each feature belongs to and in which client UI it is found.

The system is a three layer application. It consists of a back-end server layer hosting the database and all other logistics management, data reading and processing capabilities; an application server on the middle-tier which processes the requests to the back-end layer and provides the web UI features; and a client-layer for the end user interface. The solution can also be split in different tools and modules contained within the different products.

(6)

2.1

Back-End Server Environment

The back-end server environment basically consists of the Lavastorm Transaction Warehouse. It provides features for high volume load, parsing and federation, an advanced aggregation engine coupled with advanced fraud and usage profiling capabilities, and a flexible business rules engine to transform, enrich, and analyze data. The deployment of LTW is split on two server nodes; one for the database and one for the data reading.

The reader node uses SAS Software release 9.1.3 for parsing of any type of data files, e.g. ASN.1 files with records from switches, XML files from a prepay platform, or ASCII files with billing data. The database node hosts an Oracle 11g database with the schema holding all application objects; tables, views, packages, functions, etc. These are used for additional processing and analysis such as aggregation, alarming, and reporting, as well as the general storage of all data.

Both the reader node and the database node also have a set of application binaries used for the logistics management of the LTW application.

2.2

Application Server

The application server hosts the middle tier application software, both for the LRC application and the Jaspersoft reporting application. The application server can be a server or domain dedicated for the Lavastorm system, but as long as the resources are sufficiently allocated the software used may be hosted on an application server which is used for other applications as well.

2.2.1 Application Server

The recommended application server is WebLogic, and the supported version is 11g or higher. The application server has to be configured for optimal processing as it hosts all the middle tier application software. The application is using Java J2EE and can run on http as well as encrypted https.

2.2.2 Report Server

The Reporting in the system is using JasperReport Server from Jaspersoft, version 4.5. Reports are defined on data sources in LRC and are made accessible through the LRC web UI. The reports are organized and run through the repository provided in the Jaspersoft server but all functionality is embedded in the LRC user interface.

2.3

User Interfaces

The system has two different types of user interfaces which can be used and made accessible as needed for different user types and use cases.

2.3.1 Web Application

The LRC web application is an easy to distribute Flash application that runs in an Internet Explorer browser. The web application gives comprehensive tools to the analysts that are performing alarm and case management. It provides an integrated workflow for the analysis and has context sensitive links to templated (parameterized) queries and to reference data, e.g. subscriber

(7)

information, and it enables the user to add suspects to cases and items to pre-defined hotlists. The web application also has an advanced query tool for ad-hoc analysis of usage data or other data related to the investigation. Definitions of queries can be saved for easy access and frequent use, and reports can be defined based on any data source made available in the system.

The separate parts in the web application can be given different access to different users or different user groups.

2.3.2 Administrative Client

The administrative desktop client allows the advanced user to configure aggregates and alarms and it gives a comprehensive and flexible tool set to administrators. In the administrative parts it has all the basic system configurations, the configurations and preferences for data transfer and collections, all reference data set-up for enrichment and additional data analysis, comprehensive user administration and access control, and the advanced logistics management for scheduling and monitoring of all batch jobs.

3.0

System Functionality

3.1

Data Capture and Readers

3.1.1 Data Capture

The Lavastorm Transaction Warehouse is designed for the analysis of data records to facilitate fraud prevention, revenue assurance, and general data analysis. A foundation is the ability to acquire diverse, complex and frequently high-volume data efficiently and accurately, through acquisition techniques that are optimally aligned to each data type. The LTW provides core ETL functionality and is capable of acquiring data from virtually any external source ranging from simple or structured flat files to delimited files, and complex binary files.

In addition to the primary methods of acquiring and processing the source data, reference data and other supporting data can be brought into the system as needed through the Import File and Reference Data options in LTW. These secondary data acquisition methods are generally used for lower volume, more static, or manually initiated data sources, vs. the higher volume, automated and recurring data acquisition provided by the LTW Readers.

3.1.2 Readers

Captured record based data are loaded through Readers into the database and structured by sources and their contained types of information. The Readers are mediators that transform any data format into an extended format in the system to visualize the data and make it possible to group records in new categories. The data is then analyzed (enriched) and variables are added for a higher level of understanding of the information collected. The aggregation engine enables extraction of the data that the user would like to summarize for analyzing, monitoring and report generation.

In addition to data parsing, enrichment, and transformation functions, the Readers also make the data formats and the data fields fully visible to the users. Users with the right privileges can choose to include or exclude different fields and analysis for the different data formats one by one. This gives the users full flexibility with the data sources and its content.

(8)

The Readers used in the system are either pre-defined by Lavastorm, installed as modules, or User Defined directly in the administrative user interface. The pre-defined Readers are developed to parse and load more complex data files in format specified by vendors of different source systems, e.g. ASN.1 files from telecom switches. The User Defined Readers are possible to define by the administrator of the system for parsing of basic ASCII files, e.g. csv-files or files having information organized in fixed positions. Each Reader can have its own defined schedule to continuously collect and load data into the system.

Additional features available during the reading process are an advanced duplicate control, both on file and record level, and a correlation engine which can be configured to correlate records of different formats and types. The correlation engine will flag or remove identified records and optionally update the related record with information from the other record. There is also a purging mechanism that can clean out data older than a defined retention time per each format and data type.

3.2

Enrichment Modules

The enrichment parts of the system are managed by modules, permitting individual enrichment to be turned on and off per each source data type. Each module is defined to generate a number of additional data source fields. This analysis is based on enrichment look-up data maintained in the system.

The most flexible type of enrichment look-up is the User Defined analysis. This functionality allows the user to make their own translation of information in the source data fields, per individual field or in a combination of many fields. The purpose of this type of analysis is to more flexibly define and implement complex business rules and filters.

The LTW has predefined enrichment modules defined to specifically cater for telecom related fraud management scenarios, a few examples are:

• Countries – List of all countries and their related country codes. The country associated with a record can be derived by the number series analysis on originating and terminating phone numbers.

• Operators – List of operator name and their related codes. The operators associated with a record can be derived by the number series analysis on phone number, the IMSI number, or IP/DNS information.

• Services – List of services used in the network, for example for emergency calls, directory services and premium rate services.

• Number Series – Combines services, operators, countries, area codes etc. with number series in order to perform a complete analysis of phone numbers present in the source data. It can handle automatic import and “split” previously defined number series. This feature is useful when number portability is implemented in the network.

• Rates – The Rating Engine enables rating on any level of detail (any field included in the record). The rating functionality makes it possible to do pseudo rating, e.g. for quantification of the fraud or revenue leakage. The rating functionality supports rating on duration, as well as it provides support for next-generation service parameters such as volume, QoS, etc.

(9)

3.3

Aggregation

LTW has the ability to aggregate data, i.e. summarize detail record data to higher levels of information. Normally large quantities of data is captured and loaded each day. Aggregation is a way of organizing, summarizing and compressing data to provide fast and easy retrieval.

In order to permit extraction of data for fraud or revenue assurance analysis and trend spotting, LTW can be set to extract and aggregate an indefinite number of analysis data sets. Each analysis data set (Aggregate) can be created to focus on a specific area, e.g. records in a certain revenue stream using a specific service. Any fields from the detailed records database (original, generated or user defined) can be stored in the aggregated data sets. Summarizing and grouping data in aggregates often creates the base of information for saved queries and reports.

The picture below shows the steps in the Aggregate Definition wizard.

Aggregates can be created or removed at any time. They can be defined to analyze new data sources or new conditions related to the data. Aggregation enables analysts to change the scenarios that the system is investigating, as the world evolves. Aggregation provides analysts with immense analytical power and the flexibility to follow a chain of thought or line of investigation at high speed.

(10)

3.4

Alarm Setup

Alarms are defined in the Alarms Definition window in the administrative client. An alarm definition consists of an alarm criterion and a number of additional attributes, such as alarm level and external notification. Cases can be defined to automatically be created when an alert is triggered from an alarm definition. This is based on a field selected as case actor (Summarize By Field) from the data source used for the alarm. If the value of this field is not in an already existing case a new case will get created. The value of the selected field can also optionally be used in a look-up of additional information related to that field, e.g. information from a CRM system. Any related data found then gets added to the created case as “suspect” information.

The system provides three major alarm types based on what type of source data that is used for the alarm. The types are aggregate alarms, scanning alarms, and SQL data source alarms.

3.4.1 Aggregate Alarms

The aggregate alarm is a threshold rule that is based on cumulative values within a data set of aggregated data. The first step in defining an aggregate alarm is to set up the group levels to monitor the aggregate by, e.g. date, account, service, etc. The aggregate engine subsequently scans the aggregated data for suspected values and an alarm is triggered if a defined threshold is breached on an aggregated record.

Typical aggregate alarms relate to high volume controls over a defined period of time. As an example, aggregates can be configured to collect the profile for individual subscribers and recognize abnormal subscriber behavior. By analyzing the historical pattern for the subscriber in question, major deviations from the subscriber’s normal patterns can be detected resulting in an alert being triggered.

3.4.2 Scanning Alarms

A scanning alarm is triggered inside the Reader process when incoming records are scanned during the process of reading. Rules are defined for the scanning alarm that will cause the alarm to be triggered. The system scans each record of the source data selected to see if it meets the defined conditions. Scanning alarms are typically related to hotlist entries, e.g. when a call is made from a hot listed number, an alert will trigger.

3.4.3 SQL Data Source Alarms

A SQL data source alarm is defined against any SQL data source defined in LRC. A SQL data source is defined by an administrator and is based on a SQL against any object accessible in the system database. For example, log tables can be scanned for specific information or errors with an SQL, and any defined query in the LRC Query Builder can be published as a SQL data source. Alerts from this alarm type are triggered as the results of the SQL. The SQL data source alarms provide a wide range of flexibility and gives unlimited power to define an alarm on almost any information. These alarms are typically related to more complex scenarios or for data not registered with meta-data in LTW, e.g. if loaded directly with the Lavastorm Analytic Engine (LAE).

(11)

3.5

Logistics

The LTW Batch Manager allows the user to monitor the status of all batch jobs while running, and check the outcome of batch jobs after they have completed running. The batch manager allows an administrator of the system to easily schedule the jobs, check the status of the jobs running in the system, pause and resume the jobs, etc. It is also possible to set up alarms for when disks and table spaces are getting full, or when error conditions occur during batch processes.

The picture below shows the Batch Manager window having the Job Settings tab active, and the tree with all batch jobs partly expanded on the left pane.

3.6

User Administration

User privileges are administered in multiple ways and a set of options allows for very flexible management of user access rights and capabilities.

Users are assigned to Groups and Roles and access rights and privileges are defined toward those. It is possible for a group to contain a single user, and roles can be assigned to one or many users. One user can also belong to multiple groups and be assigned multiple roles. This makes it easy to administer and organize a variety of user profiles, as well as it is feasible for every user to have a completely customized profile. Every system part and every type of system action is included in the list of capabilities that can be allowed or restricted.

(12)

3.7

Workflow for Case Management

The Case Manager and Case Details windows are used in the process of case management. The case management features in LRC helps to streamline the process of investigation of cases so that similar cases are worked in a similar way regardless of which individual analyst is assigned to the case. This is accomplished through a workflow engine and the presentation of a case workflow in the Case Details window.

The workflow definition in LRC is automatically connected to all cases created and it can be customized so that it adjusts depending on case characteristics. The workflow provides a guideline to the analyst on how to execute the sequence of steps, as suggested or required, during an investigation of a case. The workflow also serves as a record of what actions and tasks have been carried out and completed. What workflow is presented on each and every case can be defined in rules based on the characteristics of the case or tasks already completed in the workflow of a case.

The picture below shows the Case Details window having the details tab displayed showing the workflow user interface to the right.

The workflow consists of task groups, tasks and actions. A task group holds a set of tasks and it can optionally be defined to enforce the order of the tasks contained in the group. Tasks holds the collection of related actions and each task can optionally be designated as required and have a time limit specified for a reminder to the user when no action is added. Actions are activities associated with a task that are to be carried out to complete the task. Actions can either be

(13)

external to the application, like a description of an activity related to the task, or be fully integrated in the application as Custom Actions, performed on suspects within the case.

A workflow definition can also include a configuration of state transition rules. These define what transitions are allowed to take place from one state of the case to another. For example, changes directly from an “Open” state to a “Closed” state can be disallowed.

All rules used in the workflow definition are evaluated at the time a case is opened or refreshed. The current characteristics of the case are then used to display the available task groups and tasks in the workflow and allow or disallow state transitions.

3.8

Data Sources & Data Types

A concept of data sources is available in the LRC. The following six different types of data sources are used:

• Aggregate – defined in the LTW administrative client

• Query – any query defined and saved in the LRC Query Builder • Record Type – originating from Readers run in LTW

• Resultset – any query results saved in the LRC Query Builder • SQL – a SQL defined towards accessible objects in the LRC database • Table – defined directly on any table or view accessible in the LRC database

Individual permissions on the data sources can be assigned in the LRC Explorer. Data sources of any type can be used in the definition of queries and reference data views.

Each field in a data source is assigned a system data type from a data type hierarchy defined in the LRC. The data type hierarchy starts with base types, such as Binary, Number, String and Datetime, and parent and child relationships are used to build data types relevant for the data contained. An example of parent/child relations of data types is String –> Phone Number –> A-subscriber Number.

Data types are used in several areas of the application to map one field to another or to define which fields can be used for a specific feature, e.g. in Query definition, Hotlists, Reference Data.

3.9

Context Sensitive Menu

A context sensitive menu (CSM) is available in most grids and data displays in LRC. The CSM is a menu displayed upon a right-click of an individual value. The selection of displayed menu items is based on the data type of the underlying field. The value of the field can then be used in the context of the selected menu as long as the expected data type is the same or a parent of the same. For example, in the Reference Data look-up menu, a user can right-click on a value and the Reference Data that has search fields with related data types is available and the related search field pre-populated with the value. The CSM also allows running of parameterized (templated) queries and reports, and adding of values to hotlists.

The picture below shows the context sensitive menu displayed, where the actual menu items related to CSM are marked with a red square.

(14)

3.10

Hotlist Functionality

A concept of Hotlists is available in LRC, which enables the user to re-use saved lists of values in conditions of aggregates and alarms, and as part of filter conditions in queries on data sources. Any number of hotlists can be defined and unique items can be added to each hotlist.

The definition of Hotlists is based on data types, which means that hotlists are not limited to specific types of fields. Values of fields with the same data type or a descendant data type as the data type for which the hotlist is defined can be added to the hotlist

Values added to a hotlist can include wildcards in order to enable searches for patterns. Values can be added to a hotlist from the context sensitive menu, for example by right-clicking on a data grid. The data type of the field then decides which hotlists are compatible and available to be selected. Values can also be added directly under the Administration menu where hotlists are defined.

Moreover, if defined in the Alarm Definition window in LTW, hotlist values can be added automatically into a Hotlist from a specific field value in an alarm instance.

3.11

Reference Data

Any data accessible in the LRC database can be defined to display in a Reference Data view. The data used can be native LRC or LTW data, potentially organized in a view or dedicated query; a data table imported into the database; or data made accessible to the database by other means, e.g. over a database link.

The definition of a Reference Data View creates a display layout of a selected data source in an organized and searchable way. All fields in the data source can be organized into groups, one for the search fields and one for the grid display, and additional groups added can be used to display the data in the right pane of the view. The same field can be added into multiple groups and the fields are displayed in the same order as they are defined.

User configurable Special Action buttons can be added into the Reference Data View window. By configuring URLs, these can give the user instant access to external systems or web pages. Special Actions can be parameterized to use any field value from the selected record in the Reference Data, e.g. for specific CRM look-up of a subscriber. In the above example, there are four Special

(15)

Action buttons added for lookup of the selected customer in other systems (e.g. CRM) and internet based search engines (e.g. Google).

The picture below shows an example of a Reference Data View with some customer information.

3.12

Suspect Types

A concept of Suspect Types is included in the LRC where a Suspect Type is defined and created from a Reference Data definition. The layout of a Suspect Type is used in the Suspects tab in the Case Details window. Suspects can be added automatically to cases when the case is created, based on definitions of the Alarms the case is based on. Suspects can also be added manually into a case, either directly in the Suspects tab in the Case Details window, or from a selected record in a Reference Data View. Each case can hold one or several types of suspects and one individual suspect is always assigned as the main suspect.

On the Suspects tab, there is also a feature to search for similar suspects added to other cases. If similar suspects are found on other cases these are displayed in an additional grid at the bottom of the Suspects tab. The related case can be opened directly from this grid.

The picture below shows the Suspect tab of the Case Details window having a few suspects added in two different Suspect Types.

(16)

3.13

Alarm Manager & Routing Engine

The LRC Alarm Manager lets the user view and manage new alarms in the system, and add alarm instances to cases. The Alarm Manager window displays the new alarm instances in the system that has not yet been added to cases.

The alarms can be managed by the Routing Engine. The routing of alarms into cases is defined in the Alarms Definition window in the LTW administrative client. The configuration of each alarm definition contains the following properties and definitions related to Alarm Routing:

• Definition of Summarize By Fields • Default folder for new cases

• Activation for automatic creation of cases • Suspect Type associations

• Definition of Suspect fields for suspect identification

• Definition of Reference Data and its fields for suspect look-up and creation

When Alarm Routing is defined for an Alarm Definition, a routing attempt occurs on every alarm instance triggered. The automatic routing engine checks if the alarm instance can be routed to an existing case or if a new case should be created. If included in the definition, it also checks for suspects and adds suspects related to the alarm from the related reference data. The suspect lookup also occurs when alarms are added to a new or existing case from the Alarm Manager. Additionally, Routing Rules can be defined per individual case using a combination of a Summarize By Field and a specific value. If then a value of a Summarize By Field on an alarm instance is equal to what is defined in the routing rule on a case, the alarm instance is added to that case.

(17)

3.14

Explorer & Permissions

LRC organizes its own objects in a comprehensive file system. The file system holds all types of items and objects in the system (except Cases which have their own structure), and organizes them in a folder structure. The Explorer window displays the folders and items to which the user has access. Depending on the item type, items can be opened for editing or be executed from the explorer. All folders and items can individually be assigned read and/or write access permissions to users or user groups.

In the Explorer is also a Systems folder that contains some specific items, such as system specific data sources and resultsets attached to cases, and a Users folder where each user defined in the system has its own folder with individual access. A concept of Favorite items allows for favorite queries and favorite reports to be selected with easy access from a separate favorites menu.

3.15

Query Builder

An advanced and highly flexible Query Builder is part of the LRC which enables analysis of complex data. The LRC Query Builder provides an environment where the more advanced analyst can run ad-hoc queries and define and save queries for other users to either run as they are, or use as templates that can be adjusted as new needs and conditions arise. The picture below shows the Query Builder with the Tool Box, the Query Editor, and the Query Results.

Queries defined in the Query Builder can be used to select data from individual data sources or from complex combinations of multiple different types of data sources available in the system.

(18)

The Query Builder consists of a Query Editor where different components of queries are added, and a Tool Box which is specific to the selected component of the query. The basic process of defining a query starts with adding the data sources needed. If multiple data sources are used these can be added into the query in one union or in multiple parallel unions or sub-unions. The next step is to select which fields to use from each data source or to compose formula fields that can be added into the query. The data can then be filtered based on the fields in the data sources or any added formula field. Additional summarization (group by) can be added for each data source or union level, and the whole query can be sorted as desired. Defined queries can be saved in the file system for easy access and use. Saved queries are included as new data sources available for use in subsequent query definitions.

When a query is run, the results are presented in a separate window pane where additional sorting and analysis can be performed. The result can be saved as a resultset in the file system, added directly to a case, or be exported to an external file. The results from a query can also be opened in a separate window for ad-hoc visualization and further analysis.

Embedded in the Query Builder is also a concept of Template Queries. Each field defined as a filter field in a query can be defined as a Template Query Parameter, which will be displayed in a dialog window when the query is run from the Explorer. If the query is run from the context sensitive menu, the value of the field that the user right-clicked on is inserted in the selected template parameter filter. The Template Query is a feature where more advanced users can define complex queries and provide easy access to them for analysts in the daily analysis and case resolution.

3.16

Ad-Hoc Visualization

(19)

The ad-hoc visualization enables basic reporting on any results generated in LRC Query Builder. The fully integrated Jaspersoft ad-hoc report designer allows the user to display the result in table, chart or crosstab format. The ad-hoc visualized reports can be used for further analysis by means of selection of group and analysis fields, ad-hoc filtering, sorting and grouping, etc. The created report can also be printed or saved as a file for reference or distribution.

3.17

Report Publishing

The functionality for publishing of reports uses fully integrated features from the Jaspersoft reports server. Advanced users can import into LRC Jaspersoft report templates they have developed in the iReport Designer desktop tool from Jaspersoft. The users of LRC can then use the imported templates and map data sources and fields into a defined report. All defined and saved reports are accessible through the LRC explorer and the context sensitive right-click menu. The LRC allows permissions to be assigned and each can add selected reports as their favorites for instant access.

The picture below shows a report defined to display a chart of a usage profile for a selected account.

(20)

4.0

Technical Requirements

4.1

Client Platform

4.1.1 LRC Web Client

Operating System Windows 7 or Windows XP

Browser Support Internet Explorer 8 or higher, 32 and 64 bit Adobe Flash Player 10 or higher

Recommended Resolution Minimum 1024x768

4.1.2 LTW Administrative Client

Operating System Windows 7 or Windows XP

Oracle Connection Oracle 11g Client or Instant Client for Windows 32 or 64 bit

4.2

Server Platform

4.2.1 Hardware

Hardware Architecture SPARC64 (VII+) or 64-bit X86 (Xeon)

Operating System Solaris 10 or Red Hat Enterprise Linux (RHEL) 5

4.2.2 Minimum Sizing

Application Server 2 CPU cores, 4GB RAM Database Node 4 CPU cores, 48GB RAM

Reader Node 2 CPU cores, 16GB RAM

Actual sizing and configuration for a server environment in production must always be provided by Lavastorm technical experts. The server nodes can all reside on the same physical unit or be separated on multiple physical units. CPU and memory resources must be capped per each node either in individual servers, domains or Solaris Zones. It is not required to have all system nodes running on the same type of hardware or operating system.

(21)

4.3

Software Support

Oracle Server 11.2.0.3

SAS 9.1.3

Sun GlassFish Enterprise Server, or Oracle WebLogic Server

GlassFish 3.1 or higher

WebLogic Server 11g (10.3.1) or higher

Java JRE 1.6

JasperReport Server 4.5

5.0

System Capacity & Configuration

5.1

General Considerations

In order to reach a desired capacity for an LTW installation there are a lot of considerations on the hardware configuration. The following explains some of the major aspects related to the database node and reader node specifically.

• Direct links must be used between the database node and the reader node as it decreases network latency between the nodes.

• Higher CPU frequency means faster data processing as long as the I/O subsystem can handle I/O peaks. This means that data can be presented faster for users and data can be available sooner.

• More cores and core threads means that parallel processing can execute more efficiently which will benefit users and data availability as long as the I/O subsystem is efficient.

• More memory will make it possible to cache more data (SGA), to process data in memory (PGA Instead of Temp tablespace) and to have a more efficient parallel processing.

• Efficient job scheduling will minimize the shutdown time of the system.

• The throughput on the reader node is based on high CPU frequency together with the underlying I/O subsystem of a temporary work area on the file system(s). In order to benefit from a high CPU frequency it is important that the underlying I/O subsystem for the work area is dimensioned to cooperate with the demand of the reader processes. If possible the work area should be placed on an in-memory storage which can cater for high iops with low latency.

• For better performance it is recommended to use smaller disks striped together rather than fewer large disks.

5.2

Hardware Resources

The resources on the hardware, CPU, RAM, file system, etc. are extremely important to configure in an efficient way, especially on the LTW Reader node. This is always done independently by

(22)

Lavastorm experts for each implementation. The utilization of the resources must continuously be over looked and revised in order to avoid any constraints when the data feeds and processing needs changes over time.

The hardware sizing is dependent on many factors whereof the most important are: • Number of records on average to read and load per day

• Average size of each record

• Number of different file formats to read • Number of files per day on each format

• Required overcapacity, i.e. number of days of data required to be possible to read at maximum throughput over 24 hours

• Number of active aggregates • Average size of active aggregates

• Complexity in rating and number analysis

• Number of subscribers (or other extensive reference data) for display and data enrichment

• Number of concurrent users of the system • Data retention time

• Complexity of analytics (aggregates, alarms, LAE graphs, etc.) • General requirements on redundancy

• Backup solution in use

The Lavastorm sizing model is developed to take these factors into account but there is always an amount of ambiguity involved and additional expertise and practice are also used in the sizing exercise. The model is designed to encounter an over dimensioned capacity, enabling three days of average data to be read within 24 hours.

5.3

Data Storage

The need for storage is basically dependent on the required retention time on detailed records stored, the space used by aggregates, and the temporary storage needs for different levels of processing. The storage calculation results in a net figure for disks required, in GB or TB. In addition to the calculated net storage must also redundancy parameters be included, e.g. for RAID configurations or other types of mirrored solutions.

Lavastorm provides recommendations to each implementation, and works in close cooperation with the experts from the IT department where installing. The result is carefully derived recommendations for the unique environment and local policies on sizing, OS parameterization, and detailed configuration of file system, as well as redundancy and backup solutions.

5.4

Scalability

The Lavastorm Solution is in its modularity and flexibility highly scalable. The initial analysis can be done with the desktop only version of LAE. The deployment can then range up to multi host

(23)

environment with all parts of the system processing multibillion amounts of records for multiple types of analysis, alarming, reporting, case management, etc.

The scalability is reached by means of additional resources made available to each individual server node. It is also possible to grow and enhance a deployed system through the modularity of the solution where separate features, such as specific data collection points or particular controls, can be activated and de-activated based on temporary requirements and the actual growth plan. The solution also provides the ability to utilize multiple nodes for dedicated purposes, e.g. multiple reader nodes, clustered web servers, or a multi host server farm for LAE.

(24)

Appendix A. System Parts per Product and Client UI

System Part

Product Client UI

LRC 2.1 LTW 4.1 Web Desktop

Alarm Manager x x

Case Manager x x

Case Details (incl. Workflow) x x

Query Builder x x

Explorer (File System) x x

Reference Data View x x

Workflow Definition x x

Data Source Definition x x

Reference Data Definition x x

Hotlist Definition x x x

Report Template Import x x

Ad-Hoc Visualization x x Report Definition x x Starting Screen x x Alarm Information x x Aggregate Definition x x Alarm Definition x x x Alarm Scoring x Alarm Exclusion x Alarm Unload x

Custom Action Definition x x x

Subscriber Profile Definition - x

Subscriber Statistics - x

Subscriber Adjustment - x

Detail Query - x

(25)

Import Table x x

Import File Wizard x x

Suspense Conditions x x

Load Exclusion x x

File Transfer Jobs x x

CDR Mapping (Reader Config.) x x

Reader Paths x x

User Defined Reader x x

CDR Correlation x x

Module per Record Type x x

Prefix Filtering x x Number Plans x x Countries x x Area Codes x x Network Prefix x x Operators x x Services x x

User Defined Fields x x

Advanced User Defined Fields x x

User Defined Rounding x x

Rating x x

Time Period Analysis x x

Currency x x

Time Zones x x

Day Sets x x

IMEI Analysis x x

Traffic Routes x x

Enrichment from Reference Data x x

User Administration x x x

(26)

Hosts x x

System Fields (Parameters) x x

Audit Trail & User Log x x