HPE eIUM Overview Guide - Hewlett Packardh20628.€¦ · 3.2.4 1+1 deployment for TimesTen and...

HPE eIUM Overview GuideRelease 8.3 Feature Pack 1Part number: E0412Third Edition

Notices

Legal notice

© Copyright 2016 Hewlett Packard Enterprise Development LP

Confidential computer software. Valid license from HPE required for possession, use or copying. Consistent with FAR 12.211and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items arelicensed to the U.S. Government under vendor's standard commercial license.

The information contained herein is subject to change without notice. The only warranties for HPE products and services areset forth in the express warranty statements accompanying such products and services. Nothing herein should be construedas constituting an additional warranty. HPE shall not be liable for technical or editorial errors or omissions contained herein.

Trademarks

Oracle and Java are registered trademarks of Oracle and/or its affiliates.UNIX is a registered trademark of The Open Group.Intel and Itanium are registered trademarks of Intel Corporation in the US and other countries and are used under license.Linux is a registered trademark of Linus Torvalds in the United States.Red Hat and Enterprise Linux are registered trademarks of RedHat, Inc.Microsoft and Windows are U.S. registered trademarks of Microsoft Corporation.

All other trademarks are the property of their respective owners.

Contents iii

Contents

Notices.......................................................................................................................................................................................... ii

List of figures.............................................................................................................................................................................. v

List of tables..............................................................................................................................................................................vii

Preface...................................................................................................................................................................................... viiiAbout this guide................................................................................................................................................................................................................................................................. viiiAudience......................................................................................................................................................................................................................................................................................viiiDocument history...............................................................................................................................................................................................................................................................viiiRelated documents...........................................................................................................................................................................................................................................................viiiConventions..................................................................................................................................................................................................................................................................................xAbbreviations and definitions...................................................................................................................................................................................................................................xi

Chapter 1: Introduction to eIUM............................................................................................................................................151.1 Business problem........................................................................................................................................................................................................................................................... 151.2 Convergent active and offline mediation...............................................................................................................................................................................................171.3 Overview of eIUM..........................................................................................................................................................................................................................................................17

1.3.1 eIUM's architecture................................................................................................................................................................................................................................181.3.2 Key benefits.................................................................................................................................................................................................................................................181.3.3 eIUM core processes and components...........................................................................................................................................................................20

Chapter 2: Feature overview.................................................................................................................................................242.1 Overview of NMEs.......................................................................................................................................................................................................................................................24

2.1.1 Traditional and structured NMEs..........................................................................................................................................................................................242.2 Batch mediation.............................................................................................................................................................................................................................................................25

2.2.1 What is a collector?............................................................................................................................................................................................................................ 262.2.1.1 Collector overview..........................................................................................................................................................................................................262.2.1.2 Collector components................................................................................................................................................................................................262.2.1.3 Collector hierarchy........................................................................................................................................................................................................28

2.2.2 Batch features: eIUM rules, correlation, output format generation......................................................................................................282.2.3 Data Delivery Agent.......................................................................................................................................................................................................................... 292.2.4 File Service..................................................................................................................................................................................................................................................292.2.5 Supported data sources................................................................................................................................................................................................................ 302.2.6 Error and duplicate CDR detection and handling...............................................................................................................................................30

2.2.6.1 Overview of detecting and handling errors........................................................................................................................................ 302.2.6.2 Duplicate detector rules..........................................................................................................................................................................................312.2.6.3 Correcting error CDRs with the CDR editor........................................................................................................................................31

2.2.7 Job Distribution Service..................................................................................................................................................................................................................312.3 Active mediation...........................................................................................................................................................................................................................................................34

2.3.1 Supported protocols........................................................................................................................................................................................................................... 352.3.2 Session Server..........................................................................................................................................................................................................................................35

2.3.2.1 Session Server components................................................................................................................................................................................ 362.3.2.2 Rule chains...........................................................................................................................................................................................................................372.3.2.3 NMEStore.............................................................................................................................................................................................................................. 37

2.3.3 Real-Time Engine product extension...............................................................................................................................................................................372.3.3.1 Real-Time Engine overview.................................................................................................................................................................................382.3.3.2 VoltDB support................................................................................................................................................................................................................38

2.3.4 Load Balancer..........................................................................................................................................................................................................................................392.4 The Common Codec Framework (CCF) and eIUM Studio..................................................................................................................................................41

2.5 Management interfaces.........................................................................................................................................................................................................................................432.5.1 Launchpad....................................................................................................................................................................................................................................................432.5.2 Public Management API............................................................................................................................................................................................................... 44

2.5.2.1 The SnmpAgent component..............................................................................................................................................................................452.5.3 Operations Console............................................................................................................................................................................................................................46

2.5.3.1 Management operations and the Scheduler......................................................................................................................................482.5.4 eIUM Studio................................................................................................................................................................................................................................................51

2.5.4.1 Deployment manager.................................................................................................................................................................................................512.5.4.2 ConfigEditor.........................................................................................................................................................................................................................512.5.4.3 The BPMN2 file workflow designer............................................................................................................................................................ 532.5.4.4 Rules visualization....................................................................................................................................................................................................... 552.5.4.5 Application visualization........................................................................................................................................................................................ 56

2.5.5 Command console............................................................................................................................................................................................................................... 572.5.6 VNF Manager........................................................................................................................................................................................................................................... 57

2.6 eIUM security overview......................................................................................................................................................................................................................................... 592.6.1 W3C-compliant audit logging...................................................................................................................................................................................................60

2.7 Reference Data Manager.....................................................................................................................................................................................................................................60

Chapter 3: eIUM deployments...............................................................................................................................................633.1 Batch deployments.....................................................................................................................................................................................................................................................64

3.1.1 HA 1+1 independent management.......................................................................................................................................................................................653.1.2 HA 1+1 centralized management..........................................................................................................................................................................................663.1.3 HA N+1 independent management....................................................................................................................................................................................673.1.4 HA N+1 centralized management........................................................................................................................................................................................68

3.2 Real-Time deployments........................................................................................................................................................................................................................................ 693.2.1 Independent management - IMDB co-located........................................................................................................................................................693.2.2 Centralized management - IMDB co-located...........................................................................................................................................................703.2.3 Centralized management - IMDB remote cluster..................................................................................................................................................713.2.4 1+1 deployment for TimesTen and Oracle..................................................................................................................................................................723.2.5 1+1 deployment for VoltDB and MySQL........................................................................................................................................................................733.2.6 N+1 deployment for TimesTen and Oracle............................................................................................................................................................... 743.2.7 N+1 deployment for VoltDB and MySQL......................................................................................................................................................................75

List of figures v

List of figures

Figure 1: Convergence of networks......................................................................................................................................................................................................................................... 15

Figure 2: Mediation solution...........................................................................................................................................................................................................................................................16

Figure 3: Convergent mediation solution.......................................................................................................................................................................................................................... 17

Figure 4: eIUM high-level architecture................................................................................................................................................................................................................................ 18

Figure 5: Central management system...............................................................................................................................................................................................................................22

Figure 6: Sample NME........................................................................................................................................................................................................................................................................ 24

Figure 7: Traditional one-dimensional NMEs...............................................................................................................................................................................................................24

Figure 8: A simple structured NME....................................................................................................................................................................................................................................... 25

Figure 9: Batch mediation architecture.............................................................................................................................................................................................................................. 25

Figure 10: Collector components and their functions.......................................................................................................................................................................................... 27

Figure 11: Collector hierarchy........................................................................................................................................................................................................................................................28

Figure 12: NME process..................................................................................................................................................................................................................................................................... 29

Figure 13: Job Distribution Service..........................................................................................................................................................................................................................................32

Figure 14: JDS Cluster Manager - Operations Console.......................................................................................................................................................................................33

Figure 15: JDS Cluster Manager - Operations Console.......................................................................................................................................................................................33

Figure 16: Active mediation architecture.......................................................................................................................................................................................................................... 34

Figure 17: Session Server components............................................................................................................................................................................................................................... 36

Figure 18: Real-Time Engine logical deployment architecture....................................................................................................................................................................38

Figure 19: Load Balancer instance with multi-protocol support............................................................................................................................................................... 40

Figure 20: Real-Time Cluster.......................................................................................................................................................................................................................................................40

Figure 21: Real-Time Cluster Manager in the Operations Console..........................................................................................................................................................41

Figure 22: eIUM Studio interface views..............................................................................................................................................................................................................................42

Figure 23: Example of data parsing by XFD (without a collector)..........................................................................................................................................................43

Figure 24: Launchpad interface.................................................................................................................................................................................................................................................44

Figure 25: A free version of the SNMP MIB browser...........................................................................................................................................................................................46

Figure 26: Operations Console interface...........................................................................................................................................................................................................................47

Figure 27: BPMN2 Workflow scheduling operation example....................................................................................................................................................................... 49

Figure 28: Operations Console Scheduler wizard....................................................................................................................................................................................................50

Figure 29: Operations Console Scheduler panel.......................................................................................................................................................................................................50

Figure 30: Deployment Manager...............................................................................................................................................................................................................................................51

Figure 31: ConfigEditor launched via eIUM Studio..................................................................................................................................................................................................52

Figure 32: Create configuration template.........................................................................................................................................................................................................................53

Figure 33: BPMN2 file workflow designer in eIUM Studio...............................................................................................................................................................................54

Figure 34: Rules visualization example: AggregationScheme visualized...........................................................................................................................................55

Figure 35: Deployment visualization in eIUM Studio............................................................................................................................................................................................56

Figure 36: Application visualization annotation..........................................................................................................................................................................................................57

Figure 37: NFV reference architecture................................................................................................................................................................................................................................58

Figure 38: eIUM-based VNF with eIUM VNF Manager......................................................................................................................................................................................59

Figure 39: VNF Manager interfaces.......................................................................................................................................................................................................................................59

Figure 40: RDM main screen........................................................................................................................................................................................................................................................ 61

Figure 41: RDM Table Edit View............................................................................................................................................................................................................................................... 61

Figure 42: RDM process....................................................................................................................................................................................................................................................................62

Figure 43: eIUM sample deployment...................................................................................................................................................................................................................................64

Figure 44: Deployment for HA 1+1 independent management.................................................................................................................................................................65

Figure 45: Deployment for HA 1+1 centralized management......................................................................................................................................................................66

Figure 46: Deployment for HA N+1 independent management...............................................................................................................................................................67

Figure 47: Deployment for HA N+1 centralized management....................................................................................................................................................................68

Figure 48: Deployment for independent management - IMDB co-located....................................................................................................................................69

Figure 49: Deployment for centralized management - IMDB co-located........................................................................................................................................ 70

Figure 50: Deployment for centralized management - IMDB remote cluster............................................................................................................................... 71

Figure 51: 1+1 deployment for TimesTen and Oracle...........................................................................................................................................................................................72

Figure 52: 1+1 deployment for VoltDB and MySQL............................................................................................................................................................................................... 73

Figure 53: N+1 deployment for TimesTen and Oracle........................................................................................................................................................................................74

Figure 54: N+1 deployment for VoltDB and MySQL.............................................................................................................................................................................................75

List of tables vii

List of tables

Table 1: Abbreviations........................................................................................................................................................................................................................................................................... xi

Table 2: eIUM processes...................................................................................................................................................................................................................................................................20

Preface viii

Preface

This chapter provides information for the intended audience on the document, document history, related documents,typological conventions, and the definitions and abbreviations used.

About this guideThe HPE Internet Usage Manager (eIUM) software enables service providers to analyze the usage of their infrastructure andbill customers accordingly. It also provides service authorization and protocol translation capabilities. This guide describes themain concepts and overall architecture of eIUM.

eIUM is one of the leading convergent mediation and usage management platforms for voice, IMS, DSL, cable, VoIP, 3Gmobile, WiFi/LAN, and many other networks and technologies. eIUM is a real-time, convergent, and adaptable mediationplatform that can help you to mediate networks for billing, monitor and manage the quality of service and capacity, and it canprepare you for future IMS networks.

For examples of eIUM in action, refer to the IUM Voice and Convergent Mediation Case Study and the WiFi®/WLAN CaseStudy - A Real-Time Prepaid Solution for Wireless HotSpot Services. Also refer to the HPE eIUM Administrator's Guide, theHPE eIUM Real-Time Guide, and the HPE eIUM Foundation Guide.

NOTICE: Though not certified for the current release, this guide still contains some content and references related tothe HP-UX and Solaris platforms.

AudienceThis guide is intended for new employees, prospective clients, and new clients wishing to familiarize themselves with eIUM.

Document historyThe following table lists the publication history of this document.

Edition Version Publication date

First Edition 8.0 Feature Pack 2 August 2014

Second Edition 8.3 April 2015

Third 8.3 Feature Pack 1 April 2016

Related documentsSee the following documents (including this document) for further information.

Document title Description

HPE eIUM Release Notes Provides release-specific topics, for example, new features, software and hardwarerequirements, and known problems and workarounds.

Preface ix


HPE eIUM Overview Guide Provides a general overview of eIUM, explains key concepts, and introduces themost important GUIs of the solution, including:

• Batch mediation• Active mediation• Session Server• Real-Time Engine• Launchpad• Operations Console• Common Codec Framework• eIUM Studio• Reference Data Manager• Deployment scenarios

HPE eIUM Foundation Guide Provides HPE eIUM concepts and design guidelines, including:

• Collectors and collector components• Designing and configuring an HPE eIUM deployment• CDR detection and error handling• File services and Data Delivery Agent• Using NMEs and the NME Schema Editor• Creating reports and auditing• Managing HPE eIUM with OpenView

HPE eIUM Installation Guide Provides installation-related topics, including:

• System requirements and installation prerequisites• HPE eIUM installation and activation instructions• MySQL database installation and activation instructions• HPE eIUM upgrade instructions• How to activate additional components• Securing HPE eIUM• Deactivating and uninstalling HPE eIUM

HPE eIUM Administrator's Guide Provides configuration and administrative guidelines, including:

• Using the HPE eIUM Launchpad, the Operations Console access, the HPEeIUM commands, and the HPE eIUM Console

• Creating and managing collectors and other servers• Managing host systems and the configuration server• Managing users and security• Correcting CDRs with the CDR Editor• Backing up your deployment• Maintaining and troubleshooting HPE eIUM• Tuning for performance• Administrative functions related to the Operations Console

Preface x


HPE eIUM Operations Console UserGuide

Provides Operations Console usage information (also including informationregarding the help system embedded in the web application), such as anorientation to the interface, and deployment monitoring capabilities, includingcoverage of:

• Processes and groups• Thresholds and alarms• Measurement jobs• Statistics and derived counters• Template wizard• Advanced panel

HPE eIUM Studio User Guide Provides usage information related to the eIUM Studio application, in terms ofusing:

• The Common Codec Framework (CCF) to structure and transform your data• The ConfigEditor to work with eIUM configuration• Templates in the ConfigEditor• Deployment and Rules visualization• The BPMN2 file workflow designer

HPE eIUM Template Reference Describes collector and Session Server templates pre-configured to read fromparticular data sources. The templates can be used to create collectors andSession Servers quickly.

HPE eIUM Command Reference Provides HPE eIUM available commands, all possible arguments/options, andsample usage.

HPE eIUM Real-Time Guide Describes the Session Server, the Real-Time Charging Manager based on theSession Server, and the Real-Time Engine in the HPE eIUM system.

HPE eIUM Real-Time Studio User Guide Describes how to use the eIUM Real-Time Studio to perform business, technical,or administration tasks.

Real-Time Engine Online Help Provides contextual help in eIUM Real-Time Studio.

HPE eIUM Real-Time Engine DeveloperGuide

Describes the Real-Time Engine system and functionality overview, developmentconsiderations, and reference information.

HPE eIUM Real-Time PerformanceTuning and Sizing Guide

Provides performance tuning and sizing tips and guidelines for the Real-TimeEngine.

HPE eIUM Load Balancer Guide Describes how to use the optional Load Balancer capabilities of HPE eIUM.

ConventionsUnless otherwise stated, this document uses the following typological conventions.

Courier Text It is used for filenames and their contents, computer inputsor outputs, program codes, and so on.

Italicized text It is used for labels, parameters, emphasized text, andreplaceable text.

Preface xi

bold text It is used to indicate navigation options in the interfaces; forexample, the text appearing in buttons and menu items.

<angle brackets> It is used to indicate generic variable names that must besubstituted by real values or strings.

Style conventions

Unless otherwise stated, this document uses the following style conventions for procedures:

• Before you begin—Describes prerequisites of the procedure.• About this task—Provides background information on the procedure.• Procedure—Lists procedure steps in sequence.• A paragraph after a procedure step in the Procedure section states one of the following information:

– Additional information on the procedure step.– Examples on how to operate the procedure step.– Results after the procedure step is performed.

• Results—Result to achieve after the steps in the Procedure section are completed.• What to do next—What to do after the procedure is completed.• Example—Provides an example, or use case reference on the procedure.

Abbreviations and definitions

Table 1: Abbreviations

3GPP 3rd Generation Partnership Project

AAA Authentication, Authorization, and Accounting

ABMF Account Balance Management Function

ACR Accounting-Request

AF Application Function

AoC Advice of Charge

API Application Programming Interface

AVP Attribute-Value Pair

BM Balance Management

BSSM Business Service Status Manager

CAMEL Customized Applications for Mobile network Enhanced Logic

CAP CAMEL Application Part

CAPS Call Attempt per Second

CC Charging Control

CCA Credit Control Answer

CCF Common Codec Framework

CCR Credit Control Request

Preface xii

CDR Call Data Record

CGF Charging Gateway Function

CLI Command Line Interface

CS Circuit Switched

CSCF Call Session Control Function

CSV Comma-Separated Value

DDL Data Definition Language

DPI Deep Packet Inspection

DRL Drools Rule Language

DSL Domain-Specific Language

DSN Data Source Name

eIUM Enhanced Internet Usage Manager

E-UTRAN Evolved Universal Terrestrial Radio Access Network

I18N Internationalization

FCS File Collection Service

FDS File Distribution Service

FTP File Transfer Protocol

GGSN Gateway GPRS Support Node

GMLC Gateway Mobile Location Center

GPRS General Packet Radio Service

GWT Google Web Toolkit

HTTP HyperText Transfer Protocol

IDE Integrated Development Environment

IMEI International Mobile Equipment Identity

IMS IP Multimedia core network Subsystem

IMSI International Mobile Subscriber Identity

IP Internet Protocol

IPDR Internet Protocol Data Record

ISC IMS Service Control

ISDN Integrated Services for Digital Network

IUM Internet Usage Manager

JDK Java Development Kit

JMS Java Messaging Service

JMX Java Management Extensions

JNDI Java Naming and Directory Interface

Preface xiii

JSP Java Server Pages

KPI Key Performance Indicator

LB Load Balancer

LCS Location Services

LDAP Lightweight Directory Access Protocol

LTE Long Term Evolution

MAP Mobile Application Part

MMS Multimedia Messaging Service

MNF Message Notification Framework

MSC Mobile Application Part

MSISDN Mobile Subscriber Integrated Services Digital Network-Number

MVNO Mobile Virtual Network Operator

NME Normalized Metered Event

OA&M Operations, Administration, and Management

OCS Online Charging System

OFCS Offline Charging System

ORM Object-Relational Mapping

OVO HPE OpenView Operations

P2P Peer-to-Peer

PCC Policy and Charging Control

PCEF Policy and Charging Enforcement Function

PCM Promotion and Campaign Management

P-GW PDN Gateway

PoC Push-to-talk over Cellular

POJO Plain Old Java Object

PRQ PriceRequest

PRS PriceResponse

PSTN Public Switched Telephone Network

P-GW PDN Gateway

QoE Quality of Experience

QoS Quality of Service

RDM Reference Data Manager

RDS Reference Data Service

RF Rating Function

RTC Real-Time Charging

RTP Real-Time Platform

SDK Software Development Kit

SGSN Serving GPRS Support Node

SIP Session Initiation Protocol

SMPP Short Message Peer-to-Peer

SMS Short Message Service

SMTP Simple Mail Transfer Protocol

SNAP Subscriber Network Application Policy

SNMP Simple Network Management Protocol

SOAP Simple Object Access Protocol

SPI Service Provider Interface

SPR Subscription Profile Repository

SQL Structured Query Language

SSH Secure Shell

TRQ TariffRequest

TRS TariffResponse

UDR Usage Data Record

UI User Interface

UPM Unified Policy Manager

URL Uniform Resource Locator

VEM VoltDB Enterprise Manager

VoIP Voice over Internet Protocol

WS Web Services Interface

WSDL Web Services Description Language

XDR External Data Representation

XFD XML Format Definition

Introduction to eIUM 15

Chapter 1

Introduction to eIUM

This chapter introduces the HPE Enhanced Internet Usage Manager Software (eIUM) in the context of the business problemthat it solves, its role in convergent mediation, and illustrates its high-level architecture.

1.1 Business problemThe convergence of different kinds of data traffic, and of wireline and wireless networks, presents service providers withdifficult technical challenges and attractive revenue opportunities. New access technologies, for example, broadband, fiber,and wireless, are fueling growth in data traffic, making it harder for service providers to keep pace with their competitors.Since profits from basic access provision are diminishing, service providers must offer value-added services (VAS), frommessaging to video-conferencing to Virtual Private Networks (VPN), in order to stay competitive. The challenge for serviceproviders today goes well beyond the provision of reliable bandwidth.

Figure 1: Convergence of networks

Many providers are compelled to offer data services in bundled packages with flexible billing plans. But in order to offer suchservices, providers must combine components from several different partners, suppliers, and internal systems.

In the traditional voice world, the Public Switched Telephone Network (PSTN) connection generates a Call Detail Record(CDR), which includes information about the duration, origin, and destination of the connection. Because the circuit-switchednetwork keeps good records, traditional billing systems work accurately and efficiently for voice services.

Data (IP) traffic usually presents a much more complex billing problem than voice traffic. A traditional billing system provideslittle insight into the actual use of IP networks. These systems cannot distinguish between IP traffic (for example, a video-conferencing application and basic email), and bill for content and usage accordingly.

To reliably analyze and charge for IP services, providers must be able to collect a variety of usage metrics, for example,megabytes of transferred data, number of messages sent or services used, or even the actual monetary amounts involvedin e-commerce transactions. They must then divide them into manageable aggregates of information, correlate them withuser information, and send the output to a billing or other business support system. In short, providers need a platform thatmediates between the IP service infrastructure and the business support systems.


BillingOperational

SupportSystems

Analysis and Business

Intelligence

BusinessSupportSystems

NetworkEquipment

HostSystems

Applicationsand Services

Probes

Mediation Solution

Figure 2: Mediation solution

To implement usage-based billing and management of IP-based services, service providers need to overcome severalchallenges:

• In IP networks, there is no single device that records the details of a transaction. Because network elements are notoriginally designed for measurement of IP traffic volume, collecting usage data from several sources can be a difficultprocess.

• In IP networks, a single subscriber action can involve several network elements, each performing a different operation.When a subscriber performs an action, for example, downloading a file, the business support systems may need torepresent it as a single customer usage record. The service infrastructure, however, uses many heterogeneous elements,for example, routers, Web servers, DNS, to satisfy the user's needs. Although these network elements log their activities,they do not typically identify the user. To create the customer usage record, the activities of several network elementsmust be correlated with the subscriber identity.

• IP services generate huge volumes of usage records that can overload business support systems unless the data isaggregated.

Many times information is received in less common formats, for example, in the form of X.25 data, proprietary device events,and so on. In sum, eIUM is a mediation platform that can collect usage events from network elements, aggregate and convertthe received information, and provide the material to billing or other business support systems (OSS/BSS) in a consumableformat (whether such systems perform retail or wholesale billing, fraud detection, traffic analysis, network planning, or churnmanagement). eIUM enables more accurate billing and reduced revenue leakage, by thoroughly and accurately gathering theraw network usage information and processing it more effectively and completely.

eIUM supports more than 50 data sources from different vendors, and its fast and flexible processing system enablesconverting the received inputs to many destination protocols and formats. Moreover, eIUM provides many other advancedfeatures and functionalities, so that service providers can satisfy their customers' needs in this dynamically growing, diverse,and competitive industry. They include:

• SNAP Real-Time Charging (RTC) - A charging platform supporting prepaid services, hot billing, and real-time charging byproviding a real-time authorization and accounting request and response mechanism.

• Advice of Charge (AoC) - Provides a subscriber with information about any applicable charges before the subscriber usesa service, where the subscriber must accept the charges in order to use the service.

• Bill shock prevention - Complex pricing models require operators to use safeguards and notifications for their customersto avoid bill shock. Bill shock prevention can be achieved by using real-time usage notification. As a result, customers cancontrol their data usage.

• Mediation and management of Value-Added Services provided by the operators, for example, video surveillance and logcentralization.

• Mediation and management of customers' home and factory devices, for example, smart meters, femtocells, alarms, carcomponents, and so on.

• Providing information to "Big Data" analytics.• Providing a charge-back solution for public cloud or HPE network solutions.• Providing a real-time framework for Policy and Charging Control (PCC).


1.2 Convergent active and offline mediationWith the convergence of different data types, and of wireline and mobile services, ISPs and telecommunications businessesneed to deploy new, flexible infrastructure within their networks and operational and business support systems. With time-to-market pressures, ROI concerns, and the potential risk to current production operations, new systems must be implementedin a way that maximizes the total return on assets and insulates current systems and processes from the heightened workloadbrought on by introducing new services.

eIUM provides a flexible, scalable, all-encompassing platform that supports:

• Next-generation active mediation, and online and near real-time service charging models.• Deployment of convergent mediation and usage management solutions required to operate complex service provider

infrastructures and maximize service revenue.• Mediation of incompatibilities or new protocols among telecommunications company equipment.• Mediation of the different standards, versions, protocols, bugs, or file formats.

eIUM is an independent and intermediate platform between OSS and BSS. Mediation is required between OSS and BSSbecause they have different timings, requirements, and service priorities.

BillingOperational

SupportSystems


Intelligence


Convergent Mediation Solution

MobileSwitching

Center (MSC)

ShortMessage

Service (SMS)

WirelessApplication

Protocol (WAP)

MultimediaMessaging Service

Center (MMSC)

Figure 3: Convergent mediation solution

eIUM's flexibility enables it to easily complement existing infrastructure and processes, improving investment returns, andminimizing risk. eIUM mediation solutions can be deployed quickly with predictable costs for wireline and wireless networks,to all kinds of data services, and to support prepaid and postpaid billing models. The comprehensive real-time capabilities ofeIUM enable integration and complement existing infrastructure.

1.3 Overview of eIUMeIUM is a usage mediation and management platform for wireline or wireless networks carrying data services. It employs ascalable, distributed architecture to collect, aggregate, and correlate usage data from your service infrastructure and presentthe data to your business support system for billing or analysis. eIUM can capture data from all (OSI reference model) networklayers.

eIUM can be configured to receive authorization and accounting requests from application servers and service control points,perform any needed conversion and processing on the request, query other servers (for example, rating, user repository,and balance manager), determine if a request can be granted using your business rules, and send the response back to theapplication server or service control point, all in real-time. For more information, refer to the HPE eIUM Real-Time Guide.

With deployments around the world, eIUM's flexible, modular, standards-based foundation supports many deploymentscenarios for phased evolution to next generation services and IMS. eIUM has proven to be successful in many deploymentsworldwide, and is deployed in various services, for example, in Telco 2.0, Cloud, smart metering, WiMax, WIFI, and HPENetworking with over 15 years of market experience.


1.3.1 eIUM's architectureeIUM scales horizontally across multiple networks and geographical regions. Its architecture optimizes hardware and softwaresystems, and delivers benchmarked high performance and availability with low latency, ensuring High Availability (HA) inreal-time. As a result, this allows eIUM to handle billions of CDRs/events per day (offline).

The following figure shows eIUM's high-level architecture.

Figure 4: eIUM high-level architecture

1.3.2 Key benefitseIUM is a comprehensive IP mediation and usage management solution with open interfaces to a wide range of applicationsand data sources.

It has several strategic advantages compared to competing products:

Scalability eIUM provides high performance and carrier-level scalability across multiple networks andmultiple geographical locations, and to millions of subscribers.

Many mediation platforms use a central relational datastore. Although relational datastorescan handle inputs from multiple clients, bulk inserts or the addition of clients is a costlyoperation that severely affects performance and scalability.

In contrast, each eIUM collector aggregates usage data in a compact tree data structure andthen stores it locally in its own datastore. Because only the essential views of aggregateddata are moved up the collector hierarchy, network traffic is significantly less than that in


centralized architectures. For more on this aspect of eIUM, see What is a collector? on page26.

Reliability eIUM collectors run autonomously, so if one collector fails, others can continue to collectand aggregate data. The collector's local datastore allows usage data to persist and beretrieved after a failed component has been recovered. eIUM can also be deployed on ahigh-availability platform, for example, MC/Serviceguard for HP-UX platforms or Marathonfor Windows platforms.

Extensibility eIUM's pure Java implementation allows system integrators and developers to extend eIUM'sfunctionality by creating new encapsulators, parsers, rules, or application datastores. Forexample, you can quickly develop a new encapsulator to read data from new file formats,data streams, network equipment, or APIs, and plug the encapsulator into an existingcollector. For more on these eIUM components, see What is a collector? on page 26.

Manageability eIUM allows you to distribute collectors throughout the infrastructure and yet managethe deployment centrally. eIUM achieves this by having the distributed collectors obtainconfiguration information from a central configuration server, which provides a completeview of the deployment. Collectors retain a cached record of their configuration and employa local agent to manage local collectors.

Each collector supports a notification mechanism to execute a program, script, or operatingsystem command after completing a flush of data to the datastore.

Security The eIUM security framework provides a robust authentication and authorizationenvironment, based on industry standards, to ensure security compliance. It allows youto leverage your existing IT infrastructure by integrating it with your enterprise-widesecurity infrastructure, and your external authentication systems, for example, Kerberos, NIS,LDAP, or NTLM. It supports multiple authentication mechanisms and transport protocolstransparently, and it also supports multiple profiles of transport layer security (TLS)combining authentication with optional data encryption. eIUM security also captures allactivity information for auditing purposes, and brings flexibility to credentials managementby delegating it to a mature and standard authentication system. Security helps usersto keep one secure set of credentials for access to all applications, and allows eIUM toparticipate in a single sign-on process and share enterprise-wide identities with othersystems.

Flexibility eIUM consists of general-purpose, configurable modules that can be easily adapted to meetchanging business requirements, enabling flexible online and offline charging. Operators canperform enhanced online charging in legacy and emerging next-generation environments.eIUM enables charging for many types of service and by many payment methods, via variousprotocols on different technology platforms. Flexibility is the key for mediation, as newservices and devices are introduced in OSS instead of mediation to avoid changes in the BSSlayer.

Open Standards eIUM is written mostly in 100% Java (as well as C/C++), and supports open industrystandards, for example, CORBA. It provides open, documented interfaces to allow equipmentand application vendors to input data into eIUM or export data out of it. Its plug-inarchitecture makes it easy for developers to extend its functionality, by adding new featuresor incorporating new equipment and applications.

HPE is a founding, charter member of the Internet Protocol Data Record (IPDR) industryforum, which is working on standardizing the IP Data Record collection and presentation tovarious applications.


Extensive DatabaseSupport

eIUM supports high-speed and in-memory databases that can be deployed in real-time withan IMDB. The following databases are supported:

• TimesTen (in-memory)• VoltDB (in-memory)• MySQL• Oracle

For more information, refer to the HPE eIUM Installation Guide.

1.3.3 eIUM core processes and componentseIUM consists of several important processes.

Table 2: eIUM processes

Process Description

Collector The primary constituent of eIUM mediation, a collector is a Java process that can read, normalize, filter, andaggregate usage events or session records according to specific rules. The number of collectors in yourdeployment depends on the number and variety of data sources in your infrastructure and on the amountand type of preprocessing your business application needs.

SessionServer

The session server is the main component that implements the Real-Time Charging Manager. The ChargingManager provides rule-based event processing that enables you to rapidly create new prepaid and hot-billed services. It provides authorization and accounting for individual or bundled service packages that spanmultiple service offerings and charging methods.

The session server is essentially a container that holds one or more connectors, one or more rule chains, andone or more session stores. You can configure as many session servers as you need, typically at least one foreach protocol. In a highly available environment, you might have a second standby session server for eachprimary session server. For more information, see the HPE eIUM Real-Time Guide.

ConfigurationServer

The configuration server maintains the configuration of every collector. It stores all of the configurationinformation in a central configuration store. Collectors retrieve their configuration from this configurationstore when they start up. Applications that interact with collectors query the configuration server to get acollector's CORBA address or IOR.

AdministrationAgent

Present on each host in the deployment as either a Windows service or a UNIX daemon, the admin agentis the first eIUM process to start. The admin agent then starts all other eIUM processes on that host. Italso communicates between the configuration server and the collectors.

DatabaseEngine

eIUM stores metadata and processed data in the MySQL embedded database. eIUM also allows you toconfigure a pre-existing database, such as Oracle, instead.

LaunchPad LaunchPad is the administrative interface to an eIUM deployment. It enables you to perform most tasksassociated with the deployment, from creating and configuring collectors to monitoring deployment status.


Process Description

OperationsConsole

The Operations Console is a web-based application designed for eIUM operators who need to monitor andmanage an eIUM deployment on a daily basis. Operators do not necessarily need to configure a deploymentor perform detailed operations, however, they need to know the status of all eIUM processes. In contrastto the LaunchPad, for an operator who needs to monitor and manage an eIUM deployment on a day-to-day basis to ensure that processes are running smoothly, the Operations Console is an ideal tool. Amongits capabilities, it can give you an at-a-glance, global view of the health of your eIUM deployment, view andmonitor all eIUM processes, and see alarms and problems with eIUM processes immediately. You can alsouse it to create process groups for easier monitoring and management, and view history charts to showprocess activity over time. Operators can also perform routine management operations, such as startingand stopping processes and groups. The Operations Console also provides role-based security to limitoperations capabilities for different users. For more information on the Operations Console, see the HPEeIUM Operations Console User Guide.

Correlator A special-purpose collector, a correlator reads usage data from usage collectors and session data fromsession collectors. It then combines these two sets of data, matching usage with users. For example, it maycombine usage data from Cisco routers with session data from RADIUS sessions to associate network usagewith corresponding users.

ReportCollector

A special-purpose collector, a report collector obtains processed data from other collectors and stores thereporting-related information in the database.

WebApplicationServer

A web application executed by the Apache Tomcat servlet engine (from the Apache Software Foundation)embedded in eIUM. The Web Application Server is a Java process that supports theeIUM OperationsConsole, Reference Data Manager, eIUM Reporting and eIUM Audit Reporting.

ScheduleServer

An optional process, the Schedule Server allows eIUM (or external scripts) to perform specific operations atscheduled intervals.


Process Description

ManagementServer

A real-time central server effectively used as a container for the ManagementService andPollingService. The ManagementServer is intended to serve as a back-end for all managing clients,such as the Operations Console, Reference Data Manager, and Real-Time Engine. The default managementarchitecture implies a single ManagementServer configured for a distributed eIUM deployment, but eIUMusers can also configure multiple ManagementServers for higher availability. Integrating with Real-TimeEngine product extension, it can also monitor and manage applications built on the Real-Time Engine, andother subsystems of the Real-Time Engine (for example, the eIUM repository, and the eIUM Load Balancer).The following figure shows the relationship between common eIUM components (to include the optionalReal-Time Engine and some of its components, such as the Real-Time Studio, and the management platformthat the central management server is at the core of.

Figure 5: Central management system

The central management server supports multiple active instances, and there is no shared state betweeneach instance. However, a master management server is configured in the system. When the master servercrashes, the managed server connects to the secondary instance. When the master server is recovered, themanaged server connects to the master server. The central manager can be scalable by partitioning themanaged servers. The partition of each managed server is connected to a central manager pair. In most thecases, there are two current instances to support high availability, and there is no partition required if thequantity of managed servers is small. The process quantity in most cases is two, but can be 2 * N (where N isthe partition quantity).

The central management server includes an execution profile, which is comprised of the micro kernel,common services, and an enterprise service operation manager. Using JMX or RMI, the central managementserver calls remote interfaces on the managed servers to collect system state information, and invokesmanagement interfaces on managed servers. The Real-Time Studio application need only communicate withthe central management server to monitor the whole eIUM system. For more information on the eIUM Real-Time Engine, SNAP Studio, and the Load Balancer, see their respective user guides (HPE eIUM Real-TimeGuide, HPE eIUM Real-Time Studio User Guide, and HPE eIUM Load Balancer Guide).

RepositoryServer

A server used as a content repository where you can upload, check in, and check out files so other eIUMprocesses can utilize them (for example, for use with the eIUM Console, Common Codec Framework/IUMStudio, BPMN2 Workflow Designer tool, ConfigEditor, and Real-Time Engine product extension).


Process Description

Studio Server A component of the Real-Time Engine, the Studio Server supports multiple active instances for scalability,and there is no shared state between each instance. The Real-Time Studio server is linearly scalable,and each instance can work as the backup of others. In most cases, there are two instances coexisted tosupport high-availability. Typically, there are two processes, but the process quantity can be increased toany number of processes. The Studio Server includes an execution profile, which is comprised of the microkernel, tools, common services, and application data model library. The Studio Server is also part of the Real-Time Engine Real-Time Studio subsystem, which is the integrated web-based graphical interface subsystemin the Real-Time Engine. It serves business users who need to manage a product catalog, or technical userswho want to use the advanced extension capability in the software. An Operations and Maintenance Console(OMC) for the OA&M function is also integrated in the Studio subsystem. The Real-Time Studio can be usedto design and mange real-time applications, and uses RMI to communicate with the eIUM Repository Serverto read and deploy business components. For more information, see the HPE eIUM Real-Time Guide andHPE eIUM Real-Time Studio User Guide.

Feature overview 24

Chapter 2

Feature overview

This chapter provides an overview of eIUM's key foundational concepts and components, namely:

• An overview of NMEs (Normalized Metered Events), eIUM's core internal data structure utilized by all eIUM components.• A description of eIUM's batch and active mediation features (the role of the eIUM collector in batch mediation, the session

server, Real-Time Engine, and Load Balancer in active mediation).• eIUM's management interfaces (graphical, command-line, API).• eIUM security and logging.• Reference Data Manager.

2.1 Overview of NMEsNMEs, or Normalized Metered Events, are the internal data structure used by all eIUM components. All data read andprocessed by eIUM are converted to NMEs.

Collectors process usage information by first converting raw usage or session data into an NME. NMEs are internal recordsused only by eIUM, and provide a common data structure. An NME is a record that is composed of fields that correspond tothe various fields in a record of some event. Each field of data in an NME is an NME attribute. Each NME attribute must havea name and a type. The type depends on what kind of data is being processed. The following figure shows a sample NME.The NME attributes are named in the top row and the data types are in the bottom row:

StartTime EndTime SrcIP DstIP SrcPort DstPort NumBytes NumPackets

Time Time IPAddress IPAddress Integer Integer Long Integer

Figure 6: Sample NME

Such NMEs are also referred to as "traditional" NMEs in eIUM, in contrast to "structured" NMEs (or SNMEs). For moreinformation, see Traditional and structured NMEs on page 24, as well as the eIUM Foundation Guide chapter on usingstructured NMEs for additional NME details.

2.1.1 Traditional and structured NMEsTraditional NMEs are flat one-dimensional records with no hierarchical structure. Traditional NMEs have no capacity tohandle optional data fields and they have no way of indicating whether a particular data field is set or not. Structured NMEsare a substantial improvement over traditional NMEs.

Traditional NMEs are defined by the NME schema and the parser component. The following figure shows a traditional NMEcomprising eight data fields or NME attributes. The NME attributes are of various types: time, IP address, integer (32 bits), andlong (64-bit integer).


Time Time IPAddress IPAddress Integer Integer Long Integer

Figure 7: Traditional one-dimensional NMEs

In contrast to traditional NMEs described above, structured NMEs (SNMEs) have the following capabilities:

Feature overview 25

• Structured NMEs store complete information about the hierarchical arrangement of complex data records.• Structured NMEs contain information about which data field is set and which is not.• Structured NMEs can handle optional data fields.

Structured NMEs retain all the hierarchical information of structured data. For example, the following figure shows astructured NME that consists of an NME and a “sub-NME”:

CreateTime NumRecord FileName Data

Time int string


Data: Time Time IPAddress IPAddress Port Port long int

Figure 8: A simple structured NME

NMEs are used in both the batch and active mediation aspects of eIUM (see Batch mediation on page 25 and Activemediation on page 34 for more information on batch and active mediation, respectively).

2.2 Batch mediationBatch mediation boosts the performance of eIUM's mediation system in a post-paid environment where real-time processingis not needed. eIUM's batch mediation is based on the eIUM collector, which is eIUM's basic building block. Collectors processuser sessions and usage data in batches, and then provide this data to a subsequent downstream consumer.

OtherSources

ApplicationServices

Business Applications

SessionSources

Rules Engine

Rules Engine

Store

Store

Encap

Encap

IUMConfigServer

Repository Server Management Webapp

Bill ing and Rating

BusinessIntelligence

OSS

DataWarehouse

Audit

Rules Engine

StoreEncap

ApplicationInterfaces

Host M

Administration Agent

Collect Batch Store

Collect Batch Store

Aggre

Aggre

Aggre

CollectNear Real-

Time Store

Figure 9: Batch mediation architecture

Feature overview 26

2.2.1 What is a collector?The following sections describe the collector, which is the fundamental process in an eIUM mediation system. A collectortypically reads input data from a device or file, performs some processing on the data, formats the data, and places the data ina file or database for consumption by another collector or application.

2.2.1.1 Collector overviewCollectors are one-way and batch oriented, processing the data as it arrives and providing it to a downstream consumer,possibly long after the actual usage event occurred (also referred to as "offline" mediation in eIUM).

As mentioned previously, collectors process user sessions and usage data in batches, which are defined by the flush policy(see the FlushPolicy category of components in the eIUM Component Reference). At the beginning of each flush, thecollector starts building up an existing or new aggregation tree as new user session logins and logouts occur, and as usagedata arrives. At the end of a flush, the collector persists the processed, aggregated data in a datastore. The collector optimizesits performance by persisting batches of data, rather than individual user sessions and usage data. This boosts performancein a post-paid environment where real-time processing is not needed.

2.2.1.2 Collector componentsA collector consists of the following main components:

• The encapsulator component of a collector reads usage data from a network data source, for example a file, a voice ordata switch, an application, or another collector, and places the data into a Normalized Metered Event (NME). NMEs arethe data record format used by all eIUM components, and are similar in nature to the CDR/XCDR format. See Overview ofNMEs on page 24 for more information on NMEs.

eIUM includes many encapsulators, with each encapsulator corresponding to a particular type of network data source,session source, or other data source.

• The aggregator processes the NME data.

Each NME read by the encapsulator is passed to the aggregator, or rule engine component. The aggregator implementsyour business logic, performing a wide variety of possible operations on the NMEs and storing them in an aggregationtree in memory. Aggregators can perform many operations on usage records, for example, accumulate fields from manyrecords, combine multiple records into one record, copy fields from one record to another, add fields to a record, and soon.

The aggregator meanwhile contains one (or more) aggregation schemes. Furthermore, the aggregation schemecontains one or more rules, which modify NMEs. Each NME goes through each rule and is operated on by each rule. Thereare many rules available, some of which are designed for specific purposes.

• The datastore stores the NME data and formats it for use by other collectors or applications.

Depending on the type of datastore, applications can query the NMEs in the datastore. The datastore also saves recoveryinformation to enable the collector to gracefully recover if it stops unexpectedly. Datastores can send processed data tomany different databases (MySQL), as well as third-party relational databases (Oracle, Internet Data Record), in differentoutput formats (HTML, XML, plain text).

Also see Batch features: eIUM rules, correlation, output format generation on page 28 for more information on rulesand other batch mediation features in eIUM.

NOTE: For each of these key collector components (encapsulator, aggregator, aggregation scheme, rules, datastore)there is a corresponding category of configurable components, their descriptions, and configuration samples. Theseare described in the HPE eIUM Component Reference.

Feature overview 27

NOTE:

You can have more than one encapsulator and datastore, and you can replace any component with another of thesame type.

Figure 10: Collector components and their functions

Encapsulators can read usage records from many sources:

• Voice switches, such as those from Alcatel, Ericsson, Lucent, Nokia, Nortel and Siemens.• VoIP devices.• WLAN access point devices and service control points.• AAA servers that use protocols such as Diameter and RADIUS.• IP routers, such as Cisco Netflow.• Web server log files.• Proxy server log files.• SNMP and RMON MIBs.• Mobile voice and data traffic from GSM/GPRS or CDMA switches.

Aggregators can perform many operations on usage records:

• Accumulate fields from many records.• Combine multiple records into one record.• Copy fields from one record to another.• Swap field values within a record.• Add fields to a record.• Perform arithmetic operations on numeric data.• Perform logical operations on binary data.• Filter out records based on many different conditions.• Conditional processing of records.• Query LDAP directories, DNS servers, and databases.• Group records based on any field values.

Datastores can send processed data to many different output formats:

• MySQL database, included with eIUM.• Third-party relational databases such as Oracle.• Internet Data Record (IDR) files in HTML, XML, or plain text.

Feature overview 28

eIUM also includes collector templates for quick setup of a collector. See the HPE eIUM Template Reference for a fulllist of eIUM collectors that have been preconfigured for specific data sources, and descriptions of provided collectortemplates. To collect usage records from a data source that is not in this list, you can assemble a collector from the collectorcomponents provided with the product. See the HPE eIUM Template Reference for a full list of collector components andtheir configuration details.

2.2.1.3 Collector hierarchyThe collector hierarchy is an important structure in eIUM, ensuring transformation of raw usage data into information that thebusiness and operational support systems can easily consume.

In any deployment, there are collectors that read usage and session data directly from the network elements. These “leafcollectors” perform the first level of processing close to the network and service elements, which minimizes network impactand maximizes reliability. They capture and aggregate the data they receive (or query) and hold it in memory until they havereceived all the data available for a specified time interval. They then flush the data to the local disk.

Intermediate collectors request the aggregated data from the leaf collectors and perform operations on these records. Finally,terminal collectors may obtain data from the intermediate collectors and send the processed data to the business supportsystems. The leaf, intermediate, and terminal collectors together constitute a collector hierarchy.

BillingOperational

SupportSystems


Intelligence


MobileSwitching

Center (MSC)

ShortMessage

Service (SMS)

WirelessApplication

Protocol (WAP)

MultimediaMessaging Service

Center (MMSC)

Collectors

Level 1 or ‘Leaf’ collectors at data source

Level 2, 3, etc. collectors process data from previous collectors

Figure 11: Collector hierarchy

Raw usage data is thus transformed as it moves up the collector hierarchy.

2.2.2 Batch features: eIUM rules, correlation, output format generationeIUM possesses several features in the batch mediation sphere, such as the ability to implement business rules, provideaggregation and correlation of session information, and generate outputs with specific format requirements.

As mentioned previously, the aggregation scheme in the encapsulator's aggregator can contain one or more rules, whichmodify NMEs. Rules can correspond to many different protocols, such as JDBC, LDAP, Diameter, CORBA, JMX, and so on.eIUM can interface with the following types of business logic, with respect to rules implementation. Using rules, eIUM can:

• Apply classic programming logic (conditions, loops, calculations, encrypt/decrypt data operations, filters, settings, and soon).

• Load external database tables or files as reference data tables in memory (see Reference Data Manager on page 60 formore on RDM, the Reference Data Manager web application).

• Handle duplicate CDR detection rules with different methods (see Error and duplicate CDR detection and handling onpage 30).

• Utilize lookup rules with external systems via multiples protocols (JDBC, LDAP, SNMP trap v1/v2c/v3, and many others).• Use the Reference Data Service (cached JDBC database information) for high performance and integration with RDM).• Implement a recovery control if a process crashes.

Feature overview 29

• Display usage parameter counts that can be shown in the Operations Console or other JMX tools. For more information,see the eIUM Operations Console User Guide.

eIUM also provides correlation and aggregation of session information:

• In the aggregator, an in-memory aggregation tree allows high performance for batch mediation, without the need for anin-memory database.

• Correlation of different CDR sources in-memory.

Output generation with specific format requirements allows:

• Generating multiple format outputs (ASN.1, ASCII, network-specific format, JDBC tables, and so on, using the classic eIUMframework).

• Alternatively using the new Common Codec Framework (CCF) to generate more complex, and mixed-output formatswith needed product extensions (see the CCFFileWriterFactory component in the eIUM Component Reference; thiscomponent can store structured NMEs into binary or text files, according to the format and transformation definitionsprovided). For more on CCF, see The Common Codec Framework (CCF) and eIUM Studio on page 41.

2.2.3 Data Delivery AgentThe Data Delivery Agent provides a way for a collector to proactively send data to an application.

Whenever the aggregator flushes NMEs to a datastore that has a configured Data Delivery Agent, the following occurs:

• The datastore notifies the Delivery Agent of the flush.• The Delivery Agent sends a copy of the flushed usage data and metadata to the Application Interface. The metadata

includes general information about the usage data contained in the flush.• The Application Interface sends the data to the external application using whatever mechanism is appropriate.

Figure 12: NME process

For additional details on the Delivery Agent, see the eIUM Foundation Guide chapter on understanding the Data DeliveryAgent.

2.2.4 File ServiceThe eIUM File Service reads multiple CDR files from multiple devices, typically voice switches, but it can be other file sourcesas well, and sends the CDR files to one or more collectors, thus, averting the need to have the same number of collectors asswitches.

The File Service can also read files from any other device or type of network that generates files containing usage data. Usingone collector per switch is a viable deployment, however, depending on the volume of CDRs your switches generate, fewercollectors may be a better solution for processing the CDRs.

The File Service has many benefits:

Feature overview 30

• Optimizes the usage of hardware (CPU and memory) and software by reducing the number of collectors required toprocess data.

• The File Service separates file collection from file processing. If the voice network goes down, the collector continuesto process files in the File Service. If the File Service stops responding, when it becomes operational again, it continuescollecting and processing files where it left off. If the collector stops responding, the File Service continues collecting filesfrom the voice switches and continues distributing the files to the collector when it becomes operational again.

• You can reconfigure file collection and file processing separately when you upgrade your voice switches.• You can direct files from specific switches to specific collectors.• With upcoming scheduling policies, you can configure load balancing by directing CDR files to less busy collectors.

For additional File Service details, also see the eIUM Foundation Guide chapter on this subject.

2.2.5 Supported data sources

Encapsulators can read usage records from many data sources:

• Voice switches, for example, from Alcatel, Ericsson, Lucent, Nokia, Nortel and Siemens• VoIP devices• WLAN access point devices and service control points• AAA servers that use protocols, for example, Diameter and RADIUS• IP routers, for example, Cisco Netflow• Web server log files• Proxy server log files• SNMP and RMON MIBs• Mobile voice and data traffic from GSM/GPRS or CDMA switches

Refer to the HPE eIUM Template Reference for a full list of eIUM collectors that have been preconfigured for specific datasources, as well as their configuration details. To collect usage records from a data source that is not in this list, you canassemble a collector from the collector components provided with the product.

2.2.6 Error and duplicate CDR detection and handlingA mediation system reads and processes usage records or CDRs generated by IP and voice switches. Occasionally CDRscan have invalid values in some of their attributes, typically due to certain temporary malfunctions in the switch or due tocorruption of the storage medium that is used to store the CDR. The eIUM error handling solution provides a robust andcomplete feature set for detecting, correcting, and reprocessing error CDRs.

One of the primary capabilities of eIUM as a mediation system is to provide an efficient and effective error handlingmechanism, to ensure minimum revenue leakage and proper auditing of every transaction that flows through the network.Any errors in mediation must be handled gracefully so that these errors can be caught early in the processing chain andcorrected.

The eIUM error handling solution provides a way to segregate CDRs that contain errors from valid CDRs. The error CDRsare stored in separate files of NMEs by the collector. These files can be manually edited and corrected using the CDR Editortool. After correcting the error CDRs, they can be reprocessed by a collector designed for this purpose, thus, reintroducing thecorrected NMEs back into the mediation processing chain.

2.2.6.1 Overview of detecting and handling errorseIUM encapsulators and parsers read data records, parse the fields in the data records, and place the data values into NMEattributes, as specified by the configuration. During this process of reading and parsing data records, eIUM componentsautomatically detect invalid records and automatically detect invalid data fields in the records. You can optionally configureeIUM components to check the data values in data fields and detect validation errors (eIUM does not automatically detectvalidation errors).

Feature overview 31

When an error is detected, it can be handled in several different ways. For example, the error record can be discarded, it canbe parked for later manual inspection and repair, or the error field can be marked for later manual inspection and repair. Foradditional details, see the eIUM Foundation Guide chapter on detecting and handling errors in CDRs.

2.2.6.2 Duplicate detector ruleseIUM collectors read input data from multiple data sources, for example, switches and other network elements. Variousfactors, including data being collected from multiple sources within the same network, can cause duplicate CDRs or otherusage records to enter the processing chain.

You can configure a duplicate detection mechanism to identify and prevent duplicate CDRs from entering the processingchain. This filtering mechanism consists of various duplicate detection rules that can be used in different scenarios.

eIUM provides the following duplicate detector rule components.

• DuplicateNMEDetectorRule compares a hash key of NME attributes.• DuplicateCDRDetectorRule compares a hash key of NME attributes and can compare NME attributes.• TimeHashDuplicateCDRDetectorRule compares a hash key of NME attributes.• TimeIntervalDuplicateCDRDetectorRule compares a hash key of NME attributes and can compare NME attributes.

See the eIUM Component Reference for more information on these rules. For additional details, see the eIUM FoundationGuide chapter on detecting and handling duplicate CDRs.

2.2.6.3 Correcting error CDRs with the CDR editorYou can use the CDR Editor to view the incorrect NMEs stored in the datastore file, and edit them to make corrections. Thecorrected NMEs can be saved into a file and reprocessed by another collector to feed the corrected NMEs back into themediation stream.

See the HPE eIUM Administrator's Guide for complete details on CDR Editor usage.

2.2.7 Job Distribution ServiceThe Job Distribution Service (JDS) is a batch mediation orchestration service.

This service enables a dynamic batch mediation application workflow, in which new instances of batch mediation services,such as a collector or session server, can be added or removed at run time without affecting other service instances in theworkflow. The JDS also provides load balancing and recording of events related to work distribution in a central database.

The JDS logically partitions a batch mediation application workflow into a set of clusters. Each cluster is a group ofdata-producing services and data-consuming services, as well as associated services (such as file servers) related to acoherent set of datasets. The JDS orchestrates data flow between producer and consumer batch mediation services, withineach cluster through JDS collector agents and JDS exporter agents that reside inside the batch mediation service instances(such as a collector or session server).

When the batch mediation service starts, it registers itself into the configured cluster. The orchestration is achieved using amessaging protocol that operates over Java Messaging Service (JMS). To transfer a dataset to a consumer batch mediationservice, the producer service sends a job notification to the JDS. The notification contains information describing the job,through which a consumer service can connect to a producer service and transfer the dataset.

Each producer and consumer service in a mediation workflow is interlinked with a cluster name at design time. The serviceinstances join the cluster on start-up by registering with the JDS. The JDS hosts a work queue per cluster, to distribute thedatasets (jobs) from all producing services in the cluster to all consuming services in the same cluster.

In addition to enabling a loosely coupled and dynamic cluster of producer and consumer batch mediation services, the workqueue also provides load balancing functionality and high availability without standby services. Job orchestration in JDSfunctions in the following manner:

Feature overview 32

• A solution designer creates a batch mediation service template using eIUM Studio, and saves the template in theRepository Server. The configuration template will contain a JDS agent configuration node that allows configuring a JDSserver address and cluster name.

• Using eIUM Studio, an operator creates an instance of a batch mediation service from the template and saves theinstances into the configuration server, effectively deploying it. The JDS server address and cluster name must bespecified for each such service instance.

• The producer services publish dataset jobs to the JDS. The jobs are distributed to consumer services through the workqueue. The consumer services directly connect to producer services using the data transfer protocol specified in thejob notifications, consume datasets, and notifies the JDS at various stages of processing. Communication between theproducer and consumer goes both ways: the producer notifies the consumer about the job being available and where,while a consumer notifies the producer that the job has been handled (the JDS acts as a notification broker - notificationsare sent to, and distributed from, the JDS).

• The job distribution service updates its data store to keep track of job processing, and routes notifications back toproducer processes in the cluster.

• An operator can create more instances of a specific template and deploy using eIUM Studio, to scale up processing. TheJDS will start dynamically distributing the load to the newly available instances. To scale down, the service instancescan be shut down and deleted. The JDS Cluster Manager interface in the Operations Console provides additional suchfunctionality (see below).

Data transfer between producer and consumer services can occur using a file protocol, such as SFTP, or the IPDR/SPstreaming protocol.

NOTE: IPDR/SP is a streaming protocol used to transfer record sets between eIUM collector servers and sessionservers. Some noteworthy eIUM capabilities with regard to the IPDR/SP stack are:

• Standalone IPDR/SP exporter and collector components.• Ability to transfer NME types without having to create CCF (Common Codec Framework) files describing the

format.• Zero configuration exporter and collector components.• Collectors can negotiate on a set of data fields within NME types, to be sent by an exporter.• Secured TCP connection support.

The consumer processes send notifications to the Job Distribution Process at various stages of dataset processing, enablingcentralized visibility into the batch mediation process clusters, which helps to perform data recovery in case of failure.

Figure 13: Job Distribution Service

The JDS stores all operational data gathered from message events in a central database. This data can be used to provideinsight into bottlenecks in the cluster, and dynamic rule-based scaling out or scaling in, of the process cluster throughintegration with provisioning systems. For example, the JDS can use its data model to detect a trend of too many unassigned

Feature overview 33

jobs in a particular cluster of producing services and consuming services, and raise an alarm to the management server. Anoperator can add more consumer service instances to resolve such a situation.

JDS also has the following features:

• Grouping servers in a deployment in the form of clusters - The JDS supports grouping servers in a deployment asclusters. A cluster groups the servers in one work flow application. The interlink between servers in a cluster are organizedas sessions.

• JDS Cluster graphical interface in the eIUM Operations Console - The eIUM Operations Console allows visualizing JDSclusters. This JDS Cluster panel interface provides functions to control server operations, and to scale up or scale downthe cluster with new server instances.

Figure 14: JDS Cluster Manager - Operations Console

Figure 15: JDS Cluster Manager - Operations Console• JDS command-line tools - The jdsmanager command-line interface tool includes cluster manager operations.• JDS server High Availability (HA) - The JDS supports High Availability (HA), relying on the database as the single point

of failure and the persistence engine. A cluster can define a set of JDS servers, potentially distributed across differenthosts in the deployment, all configured with a single shared database. At any given time, one server will be active, and theremainder will be standby servers, one of which takes over as the active on losing the current active server.

Feature overview 34

• JDS metadata - The JDS collects and records information from the servers in a cluster (for example, parameters such asrecord count, checksum, and size).

• JDS KPI - The JDS publishes KPI parameters to the eIUM management server. These KPI parameters include averagerecord size, average record count, record set size, failed job count, re-processed job count, and so on.

• JDS error management - The JDS can handle the following error scenarios:

– A server in the cluster failing to notify the JDS server with the new job notification.– A server in the cluster accepting a new job, but failing to process the job further.– A server in the in the cluster accepted the job and transferred the data file, but failed to complete the job.– A server in the cluster completed processing data and did a flush, but fails to notify the JDS server regarding it.

• JDS database query handling with optional caching - The JDS server provides an optional data caching feature,to improve database access times. Since the JDS server needs frequent database access during server notificationprocessing, this improves overall server throughput.

For more on the Job Distribution Service, see the eIUM Foundation Guide.

2.3 Active mediationeIUM supports the mediation of prepaid services, hot billing, and real-time charging by providing a real-time authorizationand accounting request and response mechanism. eIUM can be configured to perform these operations, all in real time. Foractive mediation processes, eIUM consists of the following main components: the Session Server and Real-Time Engine.

Network

Devices

User/Home

Devices

Business Applications

High Performance Data Access (In Memory DB+ DAL DataGrid)

Encap

Encap

IUMConfigServer Repository

Server ManagementWebapp

Bill ing and Rating

BusinessIntelligence

OSS

DataWarehouse

Audit

Encap

ApplicationInterfaces

Host C

Host B

Host L

Host A

Host M

Administration Agent

Advanced Use Cases

High Performance Data Access (In-Memory Database)

Rules Engine Store

Rules Engine Store

Rules Engine Store

StoreReal-Time(Session Server)

Connector

Real-Time(Session Server)

Real-Time Application

StoreConnector

LoadBalancer

(Session Server)Connector

Real-Time(Session Server)

Real-Time Application

StoreConnector

Aggre

Aggre

Aggre

Figure 16: Active mediation architecture

Feature overview 35

2.3.1 Supported protocols

A session server (see Session Server on page 35) can act as a Diameter server or client, receiving, decoding andresponding to Diameter requests and Attribute-Value Pairs (AVPs) as a Diameter server, or generating Diameter requests asa Diameter client. The Diameter protocol was designed as an improved version of the Remote Access Dial-In User Services(RADIUS) protocol. The RADIUS protocol has been widely and successfully deployed to provide authentication, authorization,and accounting (AAA) services for dial-up PPP/IP and Mobile IP access. However, inherent shortcomings of the RADIUSprotocol have limited its ability to adapt to the ever-increasing capabilities of routers and network access servers (NAS), andthe ever-expanding set of desired AAA services.

The session server can also perform as a RADIUS server, receiving Start, Stop, and Accounting requests, and responding tothe RADIUS client. The RADIUS protocol is commonly used by various switches to authorize a user and export accountinginformation. RADIUS is a reliable request/response protocol.

The GTP' protocol (Accounting/Authorization) is commonly used by GSN switches to export accounting information. TheCisco CSG uses this protocol to perform authorization. The session server can receive GTP’ messages and perform theappropriate authorization actions based on your business logic.

The Hypertext Transfer Protocol (HTTP) is an application protocol for distributed, collaborative, hypermedia informationsystems. HTTP is the foundation of data communication for the World Wide Web. Hypertext is structured text that useslogical links (hyperlinks) between nodes containing text. HTTP is the protocol to exchange or transfer hypertext. The sessionserver can be configured to send and receive non-blocking HTTP messages based on your business logic.

eIUM supports many other common protocols, such as the following:

• SOAP• LDAP• SNMP• JMX• CORBA• SMPP• JMS• SMPP

2.3.2 Session ServerThe session server is essentially a container that holds zero, one, or more session stores, one or more connectors, and oneor more rule chains. In addition, it can be used to configure an NME store to store NMEs for later processing. This sectiondescribes the session server features.

You can configure as many session servers as you need, typically at least one for each protocol. In a highly available (HA)environment, a second standby session server can be set up for each primary session server. The session server in eIUM cansupport prepaid services, hot billing, and real-time charging by providing a real-time authorization and accounting requestand response mechanism. It also supports two-way communications, protocol conversion, and real-time response. In addition,the session server provides session information storage and NME storage for later processing. The main features are:

Two-Way Request/Response Model

The session server provides two-way communication between application servers andbusiness support systems, for example, rating, billing, and fraud management applications. Itreceives service requests, queries other relevant applications, determines the response, andreturns a response to the application server. In contrast, in a postpaid environment, all usagerecords typically flow through the mediation system in one direction, after the service hasbeen delivered.

A session server both receives input from a client and responds to the client. When thesession server receives a request from a client, it converts the request to an NME and passesthe NME to the Rule Engine, the same as an eIUM collector. The session server's Rule

Feature overview 36

Engine contains rules, also the same as a collector, that can process the incoming NME, andquery other applications, for example, a user repository, rating engine, balance manager,authorization server, or virtually any other application or server. Based on the results of thequery, the session server can respond to the original request in real time.

Protocol Conversion The session server can convert between virtually any protocols, record formats, or fileformats. It can receive authorization requests, accounting requests, stop requests, and anyother type of requests in Diameter, RADIUS, GTP’, or any other protocol. It can query virtuallyany external business support application, for example, rating or billing.

Real-Time Response The session server is multi-threaded and tuned for performance to provide access tosubscriber authorization services, and respond to each subscriber request in real time.You can also use a reauthorization list to provide nearly instantaneous responses tomost subscribers. The reauthorization list keeps track of subscribers who have recentlybeen denied access. You can give immediate authorization to subscribers not on the list,followed by asynchronous authorization. You can perform full, synchronous authorizationfor subscribers on the list. After a subscriber is authorized, they can be removed from thereauthorization list.

Session InformationStorage

The session server can save subscriber login, account, and other information betweenservice requests, if needed, for example, to keep track of amounts reserved in a subscriber'sprepaid account to pay for a requested service, or to maximize hot billing throughput.

NME Storage for LaterProcessing

With the NMEStoreRule and NMEStore components you can store any NMEs for laterprocessing. For example, you can store postpaid NMEs in the NMEStore and configure acollector to process these postpaid NMEs while the session server processes prepaid NMEs.

2.3.2.1 Session Server componentsA Session Server consists of connectors, rule chains, and session stores.

The following figure shows the primary components of a Session Server.

Figure 17: Session Server components

Session Servers consist of the following components:

• Connectors that receive requests for authorization from clients and provide responses back to those clients. They are bi-directional: data flows into the connector and back out to the requesting client.

• Rule chains that process the incoming requests and implement your business logic, possibly querying other applications.They are multi-threaded for concurrency and real-time performance.

• Session stores that hold information about your subscribers to facilitate service authorization, account management, andbilling.

• NME stores that can hold NMEs for processing by an eIUM collector or another third-party tool.

For additional details, see the eIUM Real-Time Guide.

Feature overview 37

2.3.2.2 Rule chainsRule chains implement your business logic for authorizing and tracking subscriber access to network services. Rule chainsprocess incoming requests and respond to the clients making the requests. You select and configure the rules to implementyour business logic. A Session Server can contain multiple rule chains.

Rule chains are composed of individual rules. Many varied rules are available for you to use and customize for yourenvironment. All rules are described in detail in the HPE eIUM Component Reference.

2.3.2.3 NMEStoreThe NMEStore is a component of the session server that can be used to transform the processed events into records writtento disk, in other words, it stores the NME being processed into the PersistentStore in NME native binary format.

There are two available types of NMEStores: SynchNMEStore, which stores the NME that is being processed synchronouslyimmediately upon receipt, and AsynchNMEStore, which first caches the number of NMEs in memory using a queue, andfinally stores them asynchronously using its own thread. The NMEStoreManager component also contains all the NMEStoresfor a session server. For more information, see the eIUM Real-Time Guide and the eIUM Component Reference.

2.3.3 Real-Time Engine product extensionThe Real-Time Engine platform provides a high-performance foundation for applications running on it.

The Real-Time Engine is one of several optional product extensions that you can install on top of the core IUM product, toadd additional functionality (see the eIUM Installation Guide for more information on installing product extensions). The Real-Time Engine supplies a variety of both simple and complex services to the applications built on top of the platform. Theseoptimized, reusable services are used by the applications to help perform certain functionalities, which includes the highlyconfigurable functional workflows that comprise the application, mechanisms for operational support, as well as a variety ofuseful tools.

The Real-Time engine also possesses a Service Provider Interface (SPI), which integrates with IUM connectors in the Real-Time Engine and the Load Balancer, and to support COPS (Common Open Policy Service). This common SPI integrationhelps connect the Real-Time Engine product extension and IUM together, allowing them to use the same connectorimplementation. Such an integration enables real-time applications to use a single service provider. IUM connectorsare implemented as this single service provider to allow the Real-Time Engine to use various IUM protocol connectorimplementations. As a result, IUM connectors can be leveraged in the Real-Time Engine workflow. The Real-Time Engineintegrates with the following IUM protocols (and the corresponding connectors) to provide a Service Provider Interface forreal-time applications:

• Diameter (DiameterAdapter)• RADIUS (RadiusAdapter)• NME RPC (NMERPCServerAdapter/NMERPCClientAdapter)• COPS (PacketCableCOPSProtocol; also see the COPS category of components in the eIUM Component Reference)

All these connectors can also be leveraged in constructing the Load Balancer mechanism. The Load Balancer can usethese connectors and work to distribute requests for these protocols. For more information on the Load Balancer, see LoadBalancer on page 39. For additional details on the Real-Time Engine product extension, see the eIUM Real-Time Guide.

Feature overview 38

2.3.3.1 Real-Time Engine overview

Figure 18: Real-Time Engine logical deployment architecture

The Real-Time Engine runs inside the IUM Session Server, and shares infrastructure with IUM in the following aspects:

• Configuration server - Provides centralized configuration management.• Repository server - Stores and manages business components.• Installer - Performs installation.• Licensing - Provides overall IUM license management.• Security server - Provides user/role management and authentication service.• Logging - Records logs in the file system or in a database to track runtime events, and troubleshoot problems.• Central management server - Monitors deployment via JMX.• Admin agent - Starts/stops processes.

Real-Time Engine fundamentals

The following is an overview on how the Real-Time Engine works:

• The Real-Time Engine separates the business logic from the system configuration, and stores the business logic in therepository. You can use eIUM Real-Time Studio to manage the business logic components. This graphical user interfaceis used to define business logic components called entities, and their associated data requirements, validate the structureof the entities, and package newly defined or updated entities for deposits in the repository. For detailed information andoperations on eIUM Real-Time Studio, refer to the HPE eIUM Real-Time Studio User Guide.

• The Real-Time Engine uses workflows to assemble services and connectors to create real-time applications.• The Real-Time Engine provides a paradigm to enable rapid application development and provide a container to run an

application.

2.3.3.2 VoltDB supportVoltDB is supported and certified with eIUM, and is a fully durable in-memory relational database.

The Real-Time Engine adopts VoltDB to combine high-velocity data ingestion, and real-time analytics and decisioning.VoltDB allows you to leverage several advantages, for example:

• High performance• Strong data consistency• Geographical redundancy support• Persistence support• Data recovery support

Feature overview 39

• Distributed and linearly scalable• Lower cost

2.3.4 Load BalancerThe eIUM Load Balancer is an eIUM session server that provides high availability, scalability, and load balancing services. Itcan receive messages from network elements, and distribute these messages to back-end servers which in turn processesthese messages.

The eIUM Load Balancer provides the following features:

• Pluggable balancing algorithms.• Session-sticky.• Web-based configuration, management, and monitoring (for example, load balancing algorithm configuration).• Overload support (load shedding and timeout of outstanding requests).• High availability (HA) and scalability.• Multi-protocol support.• High throughput and low latency.• Application-level load balancing capability at OSI stack Level 7 for different protocols, such as Diameter and Simple Object

Access Protocol (SOAP).

The Load Balancer routes and distributes requests by a distribution algorithm that supports capacity-based distribution andrule-based distribution. The routing information can be defined by the system operator, however, the Load Balancer routesthe request based on session persistence if session information is available.

The Load Balancer forwards requests from network elements (NE) to the real-time applications. It uses a routingconfiguration to determine the destination back-end servers, and routes requests to the back-end servers based on thedistribution algorithm. The Load Balancer can also detect the availability of the back-end servers and routes the request toavailable ones.

NOTE:

The distributed algorithm supports the architecture of the back-end server group and several back-end servers. In theReal-Time Engine, the back-end server is the real-time application.

Multi-protocol support

One Load Balancer instance can support multiple protocols. In the configuration in the Load Balancer instance with multi-protocol support figure below, for example, the Load Balancer instance supports SOAP and Diameter protocols. In thisconfiguration, one Load Balancer instance is configured to support two application clusters. Each input endpoint workstogether with a Load Balancer router.

Feature overview 40

Figure 19: Load Balancer instance with multi-protocol support

Real-Time Cluster ManagerThe eIUM Real-Time Cluster feature is a management component to create, maintain, and remove a real-time cluster. AneIUM real-time cluster is composed of one or more eIUM Load Balancer(s) and a group of eIUM session servers, or third-partyservers, to provide high availability (HA), scalability, and load balancing services.

Figure 20: Real-Time Cluster

eIUM provides a graphical user interface in the Operations Console for Real-Time Engine cluster management. With the RTCluster panel, users can dynamically scale out a back-end server when they need to accelerate processing ability. In addition,they can dynamically scale in a back-end server if there are too many idle resources on the back-end servers.

Feature overview 41

Figure 21: Real-Time Cluster Manager in the Operations Console

Using the Real-Time Cluster feature, you can also update Load Balancers in a cluster dynamically by changing Algorithms,and back-end servers of a back-end server group, by adding new back-end server groups, or by removing an existing back-end server group. For more information, see the eIUM Operations Console User Guide.

2.4 The Common Codec Framework (CCF) and eIUM StudioThis section describes the Common Codec Framework (CCF) in eIUM and its relation with eIUM Studio.

The Common Codec Framework (CCF) is a powerful system for structuring and transforming your data, and is comprisedof the Codec Layer, the Transformations Layer, and the Schema Layer. CCF is an evolution of the classic NME/SNME to anew representation that is based on an XML format and a standard Eclipse-based developer tool (eIUM Studio). It moreflexibly allows users to create new parser, encoder, and decoder components. CCF allows you to create new encapsulators andconfigure new formats as Diameter/RADIUS messages using the editing interface in eIUM Studio, without the need for specialcustomization.

Codec Layer

The Codec Layer in CCF is responsible for decoding and encoding data represented in different formats (binary, text, XML,and TLV formats). Primarily, the codec can read data from files and convert them to an IUM data representation (NMEs -decoding), or the other way around, and, use data stored in NMEs to produce output for external data consumers (encoding).The Codec framework itself is not aware of internal IUM data representations, however, it only decodes/encodes dataaccording to the given format definition, which corresponds to XFD (XML Format Definition Language).

Transformation Layer

The Transformations Layer is an essential part of the overall CCF infrastructure and tightly integrated with the Codec Layer.The Transformations Layer can be used both in conjunction with the Codec Layer, and as standalone.

The Transformations Layer is responsible for mappings and transformation of input data, using TX files (TransformationDefinition files: *.tx, a custom eIUM XML file format that contains the Transformations descriptors) in the eIUM Studioapplication. The Transformations Layer can be considered as the "glue" that bridges the format definition (XFD), and theschema definition (XSD), in either direction (for example, the CCF system can convert XFD -> XSD or XFD -> XSD).

The Transformations Layer functionality allows transforming (or converting) simple or structural data into different datatypes.

Feature overview 42

Schema Layer

The Schema Layer in CCF is responsible for producing the NME schema, using XSD files (XML Schema Description: *.xsd).XSD is an XML format for describing the structure of XML documents. For CCF, the XSD files describe the NME schema usedby and its components.

eIUM Studio

eIUM Studio is a powerful, dedicated, Eclipse-based graphical development environment for working with the three mainlayers in the Common Codec Framework (CCF), with corresponding views for each:

• Format Definitions designer for XFD files• Transformations designer for TX files• Schema designer for XSD files

The eIUM Studio application allows you to open and edit the files associated with each of these views, any source data files,or text or XML files. The application also provides a source-code view for all file types, in addition to the visual method forworking with the Format Definitions, Transformations, and Schemas. eIUM Studio can also validate your files to ensure thatthey are correct before check-in, and also includes several aids for working with all file types (for example, syntax highlighting,code completion, and structure tree view).

The following figure shows the main sub-panels (or views, accessed via the Window > Show View), a central editor, anddesign area.

Figure 22: eIUM Studio interface views

eIUM Studio includes a wizard interface that supports automated Schema (XSD) and Transformations (TX) generation basedon a given XFD file. eIUM Studio can also test the Common Codec Framework (CCF) encapsulator without any collectorprocess, can visualize and show records in the graphical interface, and can display how your data is parsed via XFD (withoutany collectors):

Feature overview 43

Figure 23: Example of data parsing by XFD (without a collector)

All the files you work with in eIUM Studio can be saved and worked with individually or as part of a project. The applicationfurther integrates with the eIUM repository server, where the Format Definitions (XFD), Transformations Definitions (TX), andSchema Definitions (XSD) are uploaded and referenced so other processes can share and use them.

The CCF files can be used for configuration of eIUM components. For example, a collector can be created using theCCFFileEncapsulator, and its configuration can be updated to point to the Format Definition (XFD) and Transformations (TX)files in the repository. The CCFFileWriterFactory component can be used with the FileJDBCDatastore to store structuredNMEs into binary or text files.

To support parsing and generating HTTP messages using CCF technology, the CCFContextProvider and CCFHttpRequestcomponents support decoding and encoding HTTP messages. CCFContextProvider allows HTTP requests to be parsed andresponses generated, while CCFHttpRequest allows HTTP requests to be generated. Meanwhile, the CCFResponseGeneratorcomponent generates HTTP responses, and the CCFResponseHandler component allows HTTP responses to be parsed.

For more information on eIUM Studio, see eIUM Studio on page 51, the Using the Common Codec Framework: structuringand transforming your data chapter of the eIUM Studio User Guide, and the CCF category of components in the eIUMComponent Reference.

2.5 Management interfacesThe following sections describe the main management interfaces that eIUM provides.

2.5.1 LaunchpadThe Launchpad is an important application in the eIUM product management ecosystem. It is the main tool for designing,developing, and debugging in an eIUM deployment.

You can use the Launchpad to accomplish most development and maintenance tasks with your eIUM deployment, fromimplementation, configuration, and testing, to day-to-day monitoring and administration. Using it, you can create, modify,monitor, and control collectors and other eIUM processes and servers.

Feature overview 44

Figure 24: Launchpad interface

Session servers, collectors, and other servers in your deployment are shown on the right side of the Launchpad window. Thedeployment hierarchy in the left pane shows all the hosts, session servers, collectors, and other processes and servers runningin your distributed eIUM deployment.

Some of the operations that can be performed with Launchpad include:

• Right-clicking the collector brings up a menu of operations that you can perform, for example:

– Start or stop the collector– Display its log file– View statistics about the process– Query its data– Perform diagnostics– Perform several other operations

• Right-clicking on a process (for example, a node, a collector or a configuration component) and selecting Edit allows:

– Adding configuration a sub-node– Adding an attribute– Cutting, copying, deleting, or renaming the entry

2.5.2 Public Management APIAPI access to eIUM management operations is available and open for integration with external management systems. Alongwith this, performance measurement using SNMP can also be configured.

The Public Management API is a set of management services based on ITU-T recommendations. Services are divided into thefollowing management functional areas:

• Fault management is a set of functions enabling the detection, isolation, and correction of telecommunications network/environment abnormal operation. Fault Management ensures that the service remains available, and includes the followingservices:

– Alarm Service– Alarm Management– Log Management

Feature overview 45

• Configuration management provides functions for exercising control over, identifying, collecting data from, and providingdata to Network Elements. Configuration Management includes the following services:

– Server Management– Containment Relation Service– Resource Utilization Service

• Accounting management is concerned with tracking network utilization information, such that individual users,departments, or business units can be appropriately billed or charged for accounting purposes.

• Performance management involves the periodic collection of quality of service (QOS) metrics that characterize theperformance of the network and system resources in order to find network congestion and bottlenecks, and minimizethem with consequent actions. Performance Management includes the following services:

– Threshold Management (which is a graphical utility inside the eIUM Operations Console)– Performance Measurement Service

• Security Management alerts users whenever an event indicating an attack or potential attack on system security has beendetected.

Public management is necessary because management clients are developed by the eIUM development team, integrationsolutions are developed by the eIUM field team, and integration solutions are developed by customers or partners.

2.5.2.1 The SnmpAgent componentThe SnmpAgent component represents an SNMP agent sub-configuration for the ManagementService component. eIUMsupports SNMP V1, V2C, and V3.

Simple Network Management Protocol (SNMP) is an Internet-standard protocol for managing devices on IP networks.Devices that typically support SNMP include routers, switches, servers, workstations, printers, modem racks, and so on.SNMP is used mostly in network management systems to monitor network-attached devices for conditions that warrantadministrative attention. SNMP exposes management data in the form of variables on the managed systems, which describethe system configuration. These variables can then be queried (and sometimes set) by managing applications.

The SNMP MIB describes the structure of the device subsystem management data. The information provided by the eIUMSNMP MIB is organized into several groups:

• srv: server runtime• pm: performance management• alarm: alarm management

You can use an SNMP MIB browser to request the SnmpAgent (com.hp.usage.managementservice.snmp.SnmpAgent) runningon the central management server (you can download and use a free MIB browser of your choice; the below figure representssuch an example).

Feature overview 46

Figure 25: A free version of the SNMP MIB browser

In regards to MIB scoping, eIUM defines a MIB module for a single eIUM server. While it is possible to have multiple eIUMservers on an eIUM host, or even a multi-host eIUM environment, to request a particular server, the SNMP MIB browser mustspecify the scope of the request.

• If the incoming request is an SNMP V3 request, the scope is identified by the context name specified in the requestprotocol data unit.

• If the incoming request is an SNMP V1 or V2C request, the scope is identified by the community strings.

2.5.3 Operations ConsoleThe Operations Console is a web-based application designed for eIUM operators who need to monitor and manage an eIUMdeployment on a daily basis.

Among its capabilities, it can give you an at-a-glance, global view of the health of your eIUM deployment, view and monitorall the eIUM processes (including collectors, session servers, and file services), as well as alarms and problems with eIUMprocesses. You can also use it to create process groups for easier monitoring and management, and view history chartsto show process activity over time. Operators can also perform routine management operations, for example, starting andstopping processes and groups. The Operations Console also provides role-based security to limit operations capabilities fordifferent users.

Feature overview 47

Figure 26: Operations Console interface

The Operations Console interface consists primarily of the Deployment Status Bar at the top (which displays the currentstatus of eIUM deployment as icons), and a default main Dashboard content panel below this. The content panel showsdifferent content selected from the main eIUM OpsCon drop-down menu.

The Dashboard is customizable and can display several different characteristics pertaining to the monitoring of yourdeployment, corresponding to portlets in the interface. From the Dashboard, you can check the overall health of yourdeployment or to see status at-a-glance. The Dashboard allows you to create custom views to monitor different aspects ofyour eIUM deployment. Such monitoring views can be rearranged on the interface using drag-and-drop operations. TheDashboard portlets are:

• IUM Process - List of eIUM processes filtered by state.• Chart - Chart for specific statistical attributes.• Statistical Attributes - Table with specific statistical attributes.• List of Groups - Table with groups defined in deployment.• Active Alarms - Table with active alarms.

The Deployment Status Bar also includes an intelligent search field, whose search features change depending on the selectedpanel. From the Deployment Status Bar, and besides the above Dashboard functions, you can also do the following (selectedvia the eIUM OpsCon drop-down menu):

• View and monitor the status of all eIUM hosts, as well as server processes on the Deployment panel. From this panel youcan:

– Start, stop, restart, and clean up a particular server.– Create and modify server groups.– View logs and alarms for a particular server.– View statistical attributes for a server.

• View a table of all alarmed or crashed processes on the Hot List panel.• Access the Derived Counters panel to augment existing, pre-defined statistical attributes in the Operations Console, with

custom values that you can create.• Open the Measurement Jobs panel, which allows you to create and modify "jobs" to schedule collection of statistical

values from your eIUM deployment.• Access the Thresholds panel, where you can define alarm thresholds, as threshold conditions for one or more instances

of the same managed object supporting statistical attributes. The Operations Console allows you to set threshold valuesassociated with a process' statistical attributes, and for a corresponding performance alarm to be generated when the

Feature overview 48

particular attribute exceeds its threshold. Accordingly, this capability allows an operator another method for monitoringnetwork health in the deployment. Statistical data from eIUM processes (for example, session servers, collectors, andconnectors) can be collected and analyzed so an operator can monitor and correct the behavior and effectiveness of eIUMservers.

• Access the Scheduler panel, to define workflows for execution with specified parameters, define an execution policy,and then trigger the execution of an operation. Operations can be managed accordingly on this panel, such as adding,editing, updating and deleting operations, as well as performing scheduling operations (schedule, postpone, cancel, pause/resume). Also see Management operations and the Scheduler on page 48.

• Access the Advanced panel, which is intended for advanced users or administrators that are familiar with JMX and/or JMXconsoles. This panel provides access to a raw view of MBeans registered on the remote MBean server.

• Access the RTCluster panel, to create and maintain real-time clusters, and perform load balancing functions in terms ofclusters. Operations Console users can dynamically scale out a back-end server when they need to accelerate processingability. In addition, they can dynamically scale in a back-end server if there are too many idle resources on the back-endservers. Also see Load Balancer on page 39.

• Access the JDCluster panel, to group servers in a deployment in the form of clusters, and to create and maintain them.The clusters group the servers in one work flow application. Also see Job Distribution Service on page 31.

• The Template wizard interface allows you to create new configurations using a list of predefined templates. From thisinterface, you can add new processes (Collector, FileServer, LoadBalancer, and SessionServer) directly from the OperationsConsole, based on preconfigured templates. New processes added in this manner then appear in the LaunchPad andOperations Console. You can also later use the wizard to either update or clone a preferred server.

• Manage all Operations Console preferences on the Preferences panel. From here you can customize Operations Consolevisualization, applying themes from a predefined list (for a different look and feel if desired), and saving or clearing anypreferences (such as the number of rows in table or sort order) for specific panels. Developers can also use annotations todefine page preferences.

The Operations Console also supports touch user interface interactions, as well as traditional mouse and keyboard support.For more on the Operations Console, see the eIUM Operations Console User Guide.

2.5.3.1 Management operations and the SchedulereIUM product already provides robust O&M functions for the end user. In the current release existing features were enhancedto allow machine driven simple and composite management operations for complex eIUM deployments.

Many routine management operations from previous versions of eIUM were simplified and are now automated, forcomplex solutions and within a clustered or virtualized (NFV) environment. For this purpose, a complete solution toautomate management operations is available, using the operations Scheduler (the Scheduler is also exposed in the PublicManagement API and as a management server component). The management operations themselves are implemented asBPMN2 workflows and integrated with the management server (also see The BPMN2 file workflow designer on page 53).Using eIUM studio, you can customize existing workflows and provide more complex operations based on tasks provided byeIUM studio. Workflows are also supported in a "hot-deployment" manner, so that when changes in the BPMN2 workflow areuploaded to the RepositoryServer, they will be automatically detected and downloaded, without the need for managementserver restart.

Feature overview 49

Figure 27: BPMN2 Workflow scheduling operation example

For this feature, eIUM Studio includes over 20 Management workflow tasks, which can be used for typical deploymentoperations, such as server start/stop/cleanup, as well as several cluster management operations:

• Server (start, stop, restart, cleanup, add, remove, clone)• Host (start, stop, remove, patch installation)• Cluster (enable, disable, pause, activate)• Configuration (generic update, JVM options update, server update)• Common (SSH, alarm, SCP)

Since operations and maintenance functions should not interfere with main business activities, they should be scheduled andcompleted during specific maintenance periods. In light of this, it is important to have a facility for defining and schedulingtasks required for particular maintenance operations. Using the Scheduler, an eIUM operator can select workflows forexecution with specified parameters, define an execution policy, and then trigger the execution of an operation. TheOperations Console Scheduler panel provides a table with a list of scheduled operations, as well as a wizard interface tocreate and manage scheduling operations.

Feature overview 50

Figure 28: Operations Console Scheduler wizard

Figure 29: Operations Console Scheduler panel

Via the Action menu on this panel, you can add, edit, update and delete operations, as well as perform scheduling operations(schedule, postpone, cancel, pause/resume). To create and update an operation, the Operations Console provides anassociated wizard. When a particular operation is in progress, this table provides the progress, and elapsed time. Using theAction menu, the operator can obtain a log of the selected operation with the latest information about execution.

For more information about the Scheduler panel, see the eIUM Operations Console User Guide.

Feature overview 51

2.5.4 eIUM StudioBesides being used as the central hub for working with the Common Codec Framework (CCF), eIUM Studio also has anintegrated ConfigEditor, Deployment Manager, BPMN2 file workflow designer, and support for Rules and Applicationvisualization.

2.5.4.1 Deployment managerThe Deployment Manager is an eIUM Studio tool you can use to manage, monitor, and debug an eIUM deployment.

It can be used to accomplish most development and maintenance tasks with your eIUM deployment, from implementation,configuration, and testing, to day-to-day monitoring and administration.

The Deployment View shows all the hosts, session servers, collectors, and other processes and servers running in yourdistributed eIUM deployment, and can sort them by host, state, type, or user groups.

Figure 30: Deployment Manager

This allows managing your deployment in a similar way to the Launchpad. Right-clicking the process opens a menu ofoperations that you can perform, for example:

• Start or stop the process.• Display the log file.• View statistics about the process.• Perform diagnostics.• Edit the configuration in the ConfigEditor, or modify it via the template wizard if the process was created from a template

(see ConfigEditor on page 51).• Several other operations.• For advanced users familiar with JMX, the Deployment Manager provides all MBeans registered for each process in a

deployment tree. By right-clicking on the MBean, a JMX detail view can be displayed, where you can obtain more detailedinformation about JMX attributes provided by MBeans and supported operations.

For more information on the Deployment Manager, see the eIUM Studio User Guide.

2.5.4.2 ConfigEditorThe Configuration Editor (ConfigEditor) application provides enhanced configuration editing abilities versus the LaunchPad.

Feature overview 52

The ConfigEditor is an Eclipse-based, low-memory-footprint application that enables you to have an enhanced view of theeIUM configuration. The ConfigEditor is integrated with the configuration server, and is a dedicated application meant forconfiguration work. It exists in two forms:

• The standalone ConfigEditor application, which has limited validation and code assist.• The integrated ConfigEditor application within the eIUM Studio (shown in the following figure).

Figure 31: ConfigEditor launched via eIUM Studio

Some ConfigEditor feature highlights include the following:

• Syntax highlighting and coloring. The application has a code assist feature that helps with configuration node names,attribute names, and attribute values.

• Error reporting and validation.• Auto-complete ability when entering or modifying configuration entries.• Allows working with the entire eIUM host configuration as a whole, or you can work on multiple, individual parts of the

eIUM configuration (referred to as fragments in the ConfigEditor interface) separately.• Faster and more lightweight application footprint compared to the LaunchPad.• Supports modifying the configuration in the configuration server during import of a configuration. Using a diff viewer, you

can also compare a configuration with the local history (or working copy), and compare the configuration with that on theconfiguration server itself.

• Allows working with not only the current configuration server, but also remote deployments (only unsecured remotedeployments are supported).

For more information on the ConfigEditor, see the eIUM Studio User Guide.

ConfigEditor templates

In the ConfigEditor (eIUM Studio ConfigEditor only), you can create a new template from any configuration or configurationfragment. To create a template, right-click on the top-most configuration node you want to create a template from, and selectthe Create template option.

Feature overview 53

Figure 32: Create configuration template

You can then select the configuration attributes you want to customize. You can save the generated template to a file, andthe template file can be saved in the eIUM repository and shared among multiple users. For more information, see the eIUMStudio User Guide.

2.5.4.3 The BPMN2 file workflow designerBusiness Process Model and Notation (BPMN) is a standard for business process modeling, and provides a graphical notationfor specifying business processes in a format based on flowcharting techniques.

BPMN2 file workflows in eIUM Studio are defined in a manner similar to writing a program. Namely, you can define sequencesof actions, flow controls, and variables to keep and exchange an execution state and results. The main advantage of BPMN2is that it supports creating the workflows graphically, and the eIUM Studio user only needs to enter text when it is absolutelyrequired.

Feature overview 54

Figure 33: BPMN2 file workflow designer in eIUM Studio

The BPMN2 standard includes a large number of elements to flexibly meet many user requirements when defining a process.The following is the list of supported elements available for defining file workflows.

Connectors establish links between BPMN2 elements:

• Sequence Flow

Events represent external and internal events that occur during workflow execution:

• Start: corresponds to the beginning of every workflow.• End: corresponds to the last execution element in the workflow. Workflows can have multiple end events if it has alternate

flows.

Gateways are flow control elements that allow defining different flow executions depending on the Gateway type and user-defined conditions:

• Inclusive Gateway: creates alternative flows where all paths are evaluated.• Exclusive Gateway: creates alternative flows in a process because only one of the paths can be taken (which is why it is

referred to as exclusive).

Tasks are the main building blocks for a BPMN2 process to perform its business functions. Tasks are not bound to anyprocess or its variables, but are rather integrated using input/output mapping where variables of a process are mapped with atask’s input and output data:

• File FTP Copy• File Compressor• File Copy• File Delete• File Duplicate Detection• File From Path• File Rename• File SFTP Copy

Feature overview 55

• Execute Command• Execute Script• JDS File Operation Task

Data items correspond to process variables:

• Data Object: this process variable has a graphical representation in the BPMN2 process diagram, and usually is used todefine the main data of the process.

• Process Property: this process variable has no graphical representation, and is intended for keeping internal informationabout process execution, for example, exchanging execution results between a process’ tasks.

Other elements include:

• Sub-process: defines a sub-process inside of a current process if it is required to encapsulate some process aspect forbetter graphical or logical representation.

• Call Activity: calls one workflow from another.

For more information on the BPMN2 file workflow designer, see the eIUM Foundation Guide.

2.5.4.4 Rules visualizationThe Visualize rules right-click menu option is available when a deployment configuration is opened in the ConfigEditor viaeIUM Studio (for a supported component).

This menu option is available for configuration of the RuleChainManager, RuleChain, Aggregator, and AggregationSchemecomponents. The graphical view includes information about rule names, classes, connections, conditions, and also provides amore convenient way to browse and interact with the rules execution flow.

Figure 34: Rules visualization example: AggregationScheme visualized

For more information on Rules visualization, see the eIUM Foundation Guide.

Feature overview 56

2.5.4.5 Application visualizationApplication visualization in eIUM is intended for representing graphical deployment information, with both batch and real-time servers and the data flows between them.

Figure 35: Deployment visualization in eIUM Studio

In eIUM Studio, you can produce on demand a file in BPMN2 standard format from the deployment configuration. In this file,eIUM servers are represented as boxes with corresponding names and type labels. For each input or output data flow in eIUM,a server sequence arrow is represented, and the name of that sequence arrow describes the data exchange protocol. Forexample, typical batch protocols are "file", "jds-file", "aggregationScheme", and for real-time scenarios, the common protocolfor server communication within a deployment is "NME-RPC". If the data flow source or destination cannot be recognized,and does not belong to any eIUM server, then they are modeled as BPMN2 start and end events (green and red circles,respectively).

During conversion of a deployment configuration into a BPMN2 file in eIUM Studio, different kinds of information are used:the deployment configuration with full support for links; eIUM XML component descriptions information (.chints), whichdescribes component configuration and data flow relations. Additionally, you can specify extra information using certainconfiguration annotations, which can help to properly model data flows. Those annotations are specific to applicationvisualization in eIUM, and can be specified at the host or server level.

Feature overview 57

Figure 36: Application visualization annotation

For more on application visualization, see the eIUM Studio User Guide.

2.5.5 Command consoleThe eIUM Command Console is part of a command-line framework in eIUM for executing commands in an eIUM-specificcommand line shell.

It offers a wide range of features, for example, command history, command auto-complete, in addition to displays of commandhelp and prompting of necessary arguments. The eIUM Console possesses custom scripting support, security services (forexample, login and logout), and access to eIUM services. For more information, see the eIUM Administrator's Guide.

2.5.6 VNF ManagerNetworks Functions Virtualization (NFV) is a powerful emerging technology with widespread applicability. It is concerned withvirtualizing network functions, as well as leveraging general-purpose platforms and virtualization, to provide agility, flexibility,and decoupling of network functions from physical resources.

NFV enables CSPs (Communication Service Providers) to radically reduce infrastructure capital and operational costs, andprovide a more agile environment to introduce new services more quickly, at far less cost than previous network infrastructuresystems. The main business benefits include cost/ROI, business agility, scalability, flexibility, and innovation. ETSI (theEuropean Telecommunications Standard Institute) is working on NFV and has released the first phase specifications.

In general, to implement NFV, a Network Function (NF) and its Element Manager (a component to manage the NF) have tobe virtualized as a VNF (Virtualized Network Function). NFV decouples the software implementations of Network Functionsfrom the compute, storage, and networking resources they are using. It also requires the VNF to provide not only an EM(Element Manager) to take care of the configuration and management of the network functions, but also a VNF Manager.The VNF Manager typically takes care of the VNF life cycle. It is tightly coupled to the service logic of the VNF, and thisintelligence typically comes from the VNF vendor.

The eIUM platform can be extended (using an eIUM product extension) with a standalone VNF Manager to support targetdeployment virtualization, through an integration with the Virtualized Infrastructure (VIM, NFV-O, OpenStack, an so on). TheeIUM VNF Manager aims to provide a VNF-independent approach to integrate with any existing eIUM-based VNF, and anyother VNFs without a new EM development, and provide a functionality to support de facto standards, such as OpenStackwith the NFV infrastructure.

eIUM Element Manger(s) components (such as the Operations Console, Configuration Server, and Central ManagementServer) are enhanced to implement and expose appropriate internal integration functionality to the eIUM VNF Manager,in order to fulfil various internal operations (such as scale-out/in, scale-up/down, software update, and so on) to completeexternal MANO (Management and Orchestration) operations.

The following figure (obtained from "Network Functions Virtualisation (NFV); Architectural Framework" ETSI GS NFV 002V1.1.1 (2013-10)) below describes NFV reference architectural framework.

Feature overview 58

Figure 37: NFV reference architecture

The eIUM VNF Manager is aimed to manage multiple VNFs, such as vPCRF, vOCS, and other VNFs built on eIUM. One VNFcorresponds to one eIUM deployment. Thus, there are separate eIUM configuration servers, session servers, collectors, andmanagement servers per each VNF (eIUM deployment).

The eIUM VNF Manager manages virtual machines (VM) as instances in the eIUM deployment, directly through VirtualizedInfrastructure Management, and fulfils application-level elastic operations through interacting with the eIUM ElementManagement System (OMC, or Operations, Maintenance, and Configuration instance). The following diagram illustratesfunctional architecture for an eIUM-based VNF with the eIUM VNF Manager.

Feature overview 59

Figure 38: eIUM-based VNF with eIUM VNF Manager

The following diagram summarizes the VNF Manager in terms of supported interfaces.

Figure 39: VNF Manager interfaces

The VNF Manager is based on the RESTful API, and the VNF Manager itself can be used via the vnfmtools command-line interface tool. For more information on the VNF Manager, see the eIUM Foundation Guide. For more information onvnfmtools, see the eIUM Command Reference.

2.6 eIUM security overviewThe eIUM security framework provides a robust authentication and authorization environment based on industry standardsto ensure security compliance.

Feature overview 60

eIUM security is an optional module that provides a user/role-based security function. It allows you to leverage your existingIT infrastructure by integrating with your enterprise-wide security infrastructure, and your external authentication systems, forexample, Kerberos, NIS, LDAP, or NTLM.

The eIUM security module is not configured by default. After eIUM security is set up, users need to get authenticated (witha user name and password) to use all eIUM tools, for example, LaunchPad, eIUM Command Console, Operations Console,and so on. eIUM security provides authentication and authorization services, and ensures secure communications using TLS(Transport Layer Security), protecting CORBA, RMI, HTTP, and other communications. This means all communication acrosseIUM are secure between hosts, collectors, users, processes, components and services, and so on.

The eIUM security module also captures all activity information for auditing purposes, and brings flexibility to credentialsmanagement by delegating it to a mature and standard authentication system. Security helps users to keep one secure setof credentials for access to all applications, allows eIUM participating in a single sign-on process, and share enterprise-wideidentities with other systems.

With the eIUM security framework, you can also encrypt auditing logs. Only privileged users can decrypt the encrypted logs.Furthermore, SNMP V3 support provides security features for many components used in eIUM. Users can collect securedinformation from various SNMP agents while managing systems and networks.

2.6.1 W3C-compliant audit loggingAll eIUM audit logs conform to a common format to ease log interpretation. Audit logs adhere to W3C Extended Log FileFormat and have a defined structure and field set.

In previous versions of eIUM, there was no common machine-readable format of security audit messages across all eIUMsystems. As a result, it was very difficult to correlate events from different logs and connect them to a single user action. Auditmessages were also too technical (included fully-qualified Java names of CORBA interfaces), which hampered interpretation.

Security audit logs from all eIUM sub-systems, for example, eIUM servers, the LaunchPad, web applications like theOperations Console, and so on, conform to a common format, according to the W3C Extended Log File Format (refer to http://www.w3.org/TR/WD-logfile.html). Along with standard log fields, for example, “date”, “time”, “user”, and “comment”, the W3Cstandard allows defining custom fields with an “x” prefix.

2.7 Reference Data ManagerThe Reference Data Manager (RDM) web application allows you to view, create, modify, and delete reference data stored inthe relational database (such as MySQL, Oracle, or TimesTen). You can quickly refresh this information for eIUM components,without having to restart processes or losing service.

http://www.w3.org/TR/WD-logfile.html

http://www.w3.org/TR/WD-logfile.html

Feature overview 61

Figure 40: RDM main screen

Figure 41: RDM Table Edit View

This web-based application provides the flexibility and workflow functionality needed to create a reference data environmentthat is not only secure and powerful, but easy to use as well. RDM allows managing all important internal data in onecentralized place, and to facilitate the distribution of changes in data to all systems requiring notification, on customized termsand schedules.

In conjunction with the related Reference Data Service (RDS) or other lookup rules, eIUM process (session servers andcollectors) behavior can be more readily controlled (indirectly) by an operator. When eIUM processes have been properlyconfigured beforehand to use RDS and the reference data, the RDM tool can be used to interact with and edit reference data,without the need to change the overall eIUM configuration and potentially impact other eIUM processes. RDS can run in twomodes: direct and cached. In the case of cached mode, RDM can be used to notify RDS to refresh its caches. The followingfigure shows this process:

Feature overview 62

Billing

Reference DataDatabase

Cache Refresh

RDS

IUM Process(Session

Server or Collector)

Figure 42: RDM process

RDM includes an audit Log feature to help track the changes performed on the database by different users of the RDMapplication. Unlike traditional database editors, RDM also has a robust table lookup functionality that you can leverage tosearch for exactly what you need. For more information on RDS, see the Understanding the Reference Data Service chapter ofthe eIUM Foundation Guide. For more information on the RDM web application, see the eIUM Administrator's Guide.

eIUM deployments 63

Chapter 3

eIUM deployments

Designing an eIUM deployment mainly involves configuration rules. This chapter explains the key points in designing an eIUMdeployment, and also illustrates some deployment solutions.

Designing depends on what your inputs, processing, and outputs are. For batch deployments, the following should beconsidered:

• What Business Applications eIUM provides output data to.

– Determine what applications will receive the data from eIUM. Many possible business applications can consume datafrom eIUM, for example, billing applications, rating engines, business intelligence, service activation and provisioning,customer care, data warehousing, fraud detection, and many other business support systems.

– Determine the specific data fields required by the output applications. For example, time duration of sessions,subscriber and account details, specific services used, names and types of files downloaded, phone numbers accessed,web sites and IP addresses accessed, number of bytes downloaded, messages sent, and any other specific information.

– Determine the data format required by the output applications. For example, text files, binary files, a database, or otherformats.

– Determine how to transfer the data to the output applications. For example, FTP, local files, a database, or othertransfer methods.

• What Input Data Sources provide input data to eIUM.

– Determine where the input data comes from. For example, from voice switches, IP data switches, application log files,databases, LDAP directories, or other sources.

– Determine how to transfer the input data to eIUM. For example, from local files, over FTP, FTAM, GTP', querying adatabase, or querying an LDAP directory.

– Determine the specific data fields available in the input data. For example, file names, subscriber identifiers like accountnumbers and user login names, phone numbers, IP addresses and switches traversed, session durations, services used,and other information.

– If you plan to detect and correct invalid data, determine where you will examine the data, how you want to detecterrors, and reprocess the corrected data.

– Design the level one collectors to read the input data and generate NMEs.

For both real-time and batch deployments, the following are some common considerations:

• What Processing or Business Logic eIUM performs on the data.

– Map the input data fields to the required output data fields.– Determine what transformations need to happen to the input data. For example, summing data such as the number of

minutes connected to the network, the number of bytes downloaded, the cost of each transaction, or correlating usagedata and session data.

– Determine what data must be validated. If not already designed, determine how you want to examine, detect, andhandle invalid data. For example, discard invalid data, park invalid data in separate files for later manual review, correctand reprocess the repaired data.

– Partition the data transformations among collectors and among rule chains in each collector.– Design the collectors and rule chains that transform the input data to the appropriate output data and formats and

handle data validation and reprocessing.– Build each collector and test with sample data. Build the next collector in the chain and test. Use the actual data for

sizing and performance testing.

For real-time deployments, the following are points to consider:

• Designing a real-time prepaid charging solution.

eIUM deployments 64

– Determine the services that require authorization. For example, mobile phone access, wireless network access, orpremium services.

– Determine the protocol the services use for authorization. For example, Diameter or RADIUS.– Determine the type of requests or messages to be received by the session server. For example, network connect and

disconnect requests, session start, continue and stop messages, or service authorization requests.– Determine what other applications must be queried for information to decide whether a particular subscriber is

authorized to use a particular service. For example, a user repository, a balance manager, a rating engine, or adatabase.

– Design the rule chains that receive each type of incoming request or message, the processing that must take place,and the response that must be constructed and sent back to the client.

– Build and test a session server and related components.

The following figure shows a sample deployment of eIUM that combines both online (real-time) and offline (batch) mediation.

Figure 43: eIUM sample deployment

3.1 Batch deploymentsThe following are several representative batch mediation deployment scenarios.

eIUM deployments 65

These scenarios include:

• HA 1+1 Independent Management• HA 1+1 Centralized Management• HA N+1 Independent Management• HA N+1 Centralized Management

3.1.1 HA 1+1 independent management

Figure 44: Deployment for HA 1+1 independent management

In this deployment scenario:

• There is a management server per instance, which means indirectly that there will be multiples Operations Consoles.Though two servers are acceptable, in general additional servers can result in an O&AM issue.

• Sources are typically NEP devices (MSC, GGSN) on the OSS side.• Usually an in-memory database is not required, and internal in-memory tree structures are used for aggregation.• MySQL is used as the database in the central IUM management core.• Destination systems are typically on the BSS side (billing, fraud, data retention, DWH, revenue assurance).• SAN storage is mandatory for High Availability in the centralized management cluster, and also for the application cluster.

eIUM deployments 66

3.1.2 HA 1+1 centralized management

Figure 45: Deployment for HA 1+1 centralized management


• There is a central management server for the whole system, which means a single Operations Console. SAN storage ismandatory for High Availability on the centralized management cluster.

• Sources are typically NEP devices (MSC, GGSN) on the OSS side.• Usually an in-memory database is not required, and internal in-memory tree structures are used for aggregation.• MySQL is used as the database in the central IUM management core.• Destination systems are typically on the BSS side (billing, fraud, data retention, DWH, revenue assurance).• SAN storage is mandatory for High Availability, while application cluster packages can run on any node in the cluster.• MySQL per server could also be added, or another database locally as Oracle EE.

eIUM deployments 67

3.1.3 HA N+1 independent management

Figure 46: Deployment for HA N+1 independent management


• There is a management server per instance, which means indirectly that there will be multiple Operations Consoles.Though two servers are acceptable, in general additional servers can result in an O&AM issue.

• Sources are typically NEP devices (MSC, GGSN) on the OSS side.• Usually an in-memory database is not required, and internal in-memory tree structures are used for aggregation.• MySQL is used as the database in the central IUM management core.• Destination systems are typically on the BSS side (billing, fraud, data retention, DWH, revenue assurance).• SAN storage is mandatory for High Availability in the centralized management cluster, and also for the application cluster.• HA N+1 provides an extra sparse node to be ready if one active server goes down.

eIUM deployments 68

3.1.4 HA N+1 centralized management

Figure 47: Deployment for HA N+1 centralized management


• There is a central management server for the whole system, which means a single Operations Console. SAN storage ismandatory for High Availability on the centralized management cluster.

• Sources are typically NEP devices (MSC, GGSN) on the OSS side.• Usually an in-memory database is not required, and internal in-memory tree structures are used for aggregation.• MySQL is used as the database in the central IUM management core.• Destination systems are typically on the BSS side (billing, fraud, data retention, DWH, revenue assurance).• SAN storage is mandatory for High Availability, while application cluster packages can run on any node in the cluster.• MySQL per server could also be added, or another database locally as Oracle EE.• HA N+1 provides an extra sparse node to be ready if one active server goes down.

eIUM deployments 69

3.2 Real-Time deploymentsThe Real-Time Engine is designed to support high availability (HA) and near linear scalability (scaling through addingadditional servers).

Currently, only the Real-Time Application cluster supports HA and scalability. The Real-Time Application cluster supportsan N+1 (active-active) or an N+N (active-standby) deployment. The Real-Time Application cluster also supports sessionreplication and session partition between nodes. Each session partition has at least one backup partition, and the backuppartitions of one node is distributed on other nodes. If one node crashes, the traffic of the crashed node is distributed evenly.

The Real-Time Engine supports multiple deployment scenarios for HA and scalability. The next sections provide examples forsuch deployments:

• Independent management - IMBD co-located• Central management - IMDB co-located• Central management - IMBD remote cluster• 1+1 TimesTen and Oracle• 1+1 VoltDB and MySQL• N+1 TimesTen and Oracle• N+1 VoltDB and MySQL

3.2.1 Independent management - IMDB co-located

Figure 48: Deployment for independent management - IMDB co-located


eIUM deployments 70

• There are two hosts in this deployment. Though more hosts are acceptable, in general too many hosts can cause OA&Missues.

• The Real-Time Application (Session Server) and IMDB (the in-memory database can be VoltDB or TimesTen) are co-located on one host, but they can be deployed on different hosts. The two IMDBs on different hosts replicate each other'sin-memory database to allow for High Availability (HA).

• A management server is deployed on each host, indicating multiple Operations Consoles can be used. MySQL is used asthe database in the IUM management core.

• SAN storage is mandatory for HA on the centralized management cluster. Otherwise, SAN can be optional.• In some cases, an IMDB or persistence is not needed, for example, if the Real-Time Application serves as a gateway or a

stateless engine.

3.2.2 Centralized management - IMDB co-located

Figure 49: Deployment for centralized management - IMDB co-located


• The Real-Time Application (Session Server) and IMDB (the in-memory database can be VoltDB or TimesTen) are co-located on one host, but they can be deployed on different hosts. The two IMDBs on different hosts replicate each other'sin-memory database to allow for High Availability (HA).

• MySQL is used as the database in the IUM management core.• SAN storage is mandatory for HA on the centralized management cluster. It allows using a centralized Operations Console.• In some cases, an IMDB or persistence is not needed, for example, if the Real-Time Application serves as a gateway or a

stateless engine.

eIUM deployments 71

3.2.3 Centralized management - IMDB remote cluster

Figure 50: Deployment for centralized management - IMDB remote cluster


• The Real-Time Applications (Session Servers) and IMDB (the in-memory database can be VoltDB or TimesTen) aredeployed on different hosts. VoltDB allows for dynamic cluster elasticity (TimesTen does not). The two IMDBs replicateeach other's in-memory database to allow for High Availability (HA).

• The Real-Time Applications (Session Servers) are deployed on different hosts to form a cluster.• MySQL is used as the database in the IUM management core. In some cases, MySQL can be replaced with TimesTen.• SAN storage is mandatory for HA on the centralized management cluster. It allows using a centralized Operations Console.• In some cases, an IMDB or persistence is not needed, for example, if the Real-Time Application serves as a gateway or a

stateless engine.

eIUM deployments 72

3.2.4 1+1 deployment for TimesTen and Oracle

Figure 51: 1+1 deployment for TimesTen and Oracle


• The Real-Time Application and the in-bemory cache (TimesTen) are deployed on the same host (application server).• The two Real-Time Applications replicate each other.• TimesTen and the Real-Time Application use shared memory. The Real-Time Application process and the TimesTen

process are located in the host (application server).• When the Real-Time Application accesses TimesTen, it can be considered that the Real-Time Application accesses itself

because they are in the same memory, thus, allowing for fast access.

eIUM deployments 73

• TimesTen is used as the in-memory database and Oracle is used as the database.• The Load Balancer cluster and the Real-Time Application cluster can be merged into one cluster if your deployment is a

small-production environment.

3.2.5 1+1 deployment for VoltDB and MySQL

Figure 52: 1+1 deployment for VoltDB and MySQL

eIUM deployments 74


• The Real-Time Application and the in-memory cache (VoltDB) can be deployed on different hosts (application servers).• There are two VoltDB servers in the in-memory cache cluster, and each provides an in-memory cache.• The two VoltDB servers replicate each other.• VoltDB is used as the in-memory database and MySQL is used as the database.• The in-memory cache cluster and the Real-Time Application cluster can be merged into one cluster if your deployment is

a small-production environment.

3.2.6 N+1 deployment for TimesTen and Oracle

Figure 53: N+1 deployment for TimesTen and Oracle


• The Real-Time Application and the in-memory cache (TimesTen) are deployed on the same host (application server).• The Real-Time Applications replicate each other. The whole Application cluster partitions the data and each node takes a

partial partition. Each partition has a backup partition in the cluster.• TimesTen and the Real-Time Application use shared memory. The Real-Time Application process and the TimesTen

process are located in the same host (application server).• When the Real-Time Application accesses TimesTen, it can be considered that the Real-Time Application accesses itself

because they are in the same memory cluster, thus, allowing for fast access.• TimesTen is used as the in-memory database and Oracle is used as the database.• Based on the distributed cache N+1 architecture, the Load Balancer uses a dynamic routing algorithm through the

partition.• The Load Balancer pair is configured in active-active mode and has bi-directional session replication to achieve High

Availability.

eIUM deployments 75

• The Load Balancer and back-end Real-Time Application servers share the data partition state. Each Load Balancer routesevents through the partition.

3.2.7 N+1 deployment for VoltDB and MySQL

Figure 54: N+1 deployment for VoltDB and MySQL


• The Real-Time Application and the in-memory cache (VoltDB) can be deployed on different hosts (application servers).• There are more than two VoltDB servers in the in-memory cache cluster, and each provides an in-memory cache.• The whole Application cluster partitions the data and each node takes a partial partition. Each partition has a backup

partition in the cluster.• The VoltDB servers replicate each other.• A part of the VoltDB server process is located in the Real-Time Application server. This part of the VoltDB server process

is referred to as a VoltDB client, and it runs in the Real-Time Application server.• VoltDB is used as the in-memory database and MySQL is used as the database.

eIUM deployments 76

• Based on the distributed cache N+1 architecture, the Load Balancer uses a dynamic routing algorithm through thepartition.

• The Load Balancer pair is configured in active-active mode and has bi-directional session replication to achieve HighAvailability.

HPE eIUM Overview Guide - Hewlett Packardh20628.€¦ · 3.2.4 1+1 deployment for TimesTen and...

Documents

Transcript of HPE eIUM Overview Guide - Hewlett Packardh20628.€¦ · 3.2.4 1+1 deployment for TimesTen and...