HP IUM mediation
HP OpenView Internet Usage Manager (IUM) is a usage mediation and management platform for wireline or wireless networks carrying voice or data services. IUM employs a scalable, distributed architecture to collect, aggregate, and correlate usage data from your service infrastructure and present the data to your business support system for billing or analysis. IUM can capture data from all (OSI reference model) network layers. IUM also provides a Real-Time Charging Manager that supports prepaid services, hot billing, and real-time charging by providing a real-time authorization and accounting request and response mechanism. IUM 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 such as rating, user repository, and balance manager, determine if the request can be granted using your business rules, and send the response back to the application server or service control point, all in real time.
IUM is a comprehensive usage management system with open interfaces to a wide range of applications and data sources. Its distributed architecture is designed to scale as your business grows. Whether you have ten routers or ten thousand, one thousand subscribers or ten million, IUM can be configured to effectively manage your data. IUM is one of the leading convergent mediation and usage management platforms for voice, DSL, cable, VoIP, 3G mobile, WiFi/LAN and many other networks and technologies. It is a real-time, convergent and adaptable mediation platform that can help you mediate today’s networks for billing, monitor and manager quality of service and capacity, as well as prepare you for future IMS networks (IMS =IP Multimedia Subsystem).
IUM has several strategic advantages compared to competitive products:
IUM provides carrier-level scalability across multiple networks and multiple geographical locations, and to millions of subscribers. Many mediation platforms use a central relational data store. Although relational data stores can handle inputs from multiple clients, bulk inserts or the addition of clients is a costly operation that severely affects performance and scalability. In contrast, each IUM collector aggregates usage data in a compact tree data structure and then stores it locally in its own data store. Because only the essential views of aggregated data are moved up the collector hierarchy, network traffic is significantly less than that in centralized architectures.
IUM collectors run autonomously, so if one collector fails, others can continue to gather and aggregate data. The collector’s local data store allows usage data to persist and be retrieved after a failed component has been recovered. IUM can also be deployed on a high-availability platform like MC/Serviceguard for HP-UX platforms or Marathon for Windows platforms.
System integrators and developers can easily extend IUM functionality by creating new encapsulators, parsers, rules, or application data stores by taking advantage of the extensibility and reusability of IUM’s pure Java implementation. For example, 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 existing collector.
IUM provides an optional mechanism to authenticate, authorize, and audit administration and configuration activities by users. A role based authorization model determines which actions an administrator can perform on the system. When security is activated, all administration and configuration activity is logged for auditing purposes. All communication is authenticated and encrypted using the Secure Sockets Layer (SSL). Authentication uses public key cryptography with 1024-bit RSA keys. Data is transmitted using 40-bit RC4 encryption, and is freely exportable.
IUM consists of general-purpose, configurable modules that can be easily adapted to meet changing business requirements. For example, a single rule engine can run multiple, parallel aggregation schemes to support the various needs of billing, marketing, and operations management systems.
IUM is written in 100% Java and supports open industry standards such as CORBA. It provides open, documented interfaces to allow equipment and application vendors to input data into IUM or export data out of it. Its plug-in architecture makes it easy for developers to extend its functionality by adding new features or incorporating new equipment and applications. HP is a founding, charter member of the IPDR (Internet Protocol Data Record) industry forum, which is working on standardizing the IP Data Record collection and presentation to various applications.
The primary constituent of IUM mediation, a collector is a Java process that can read, normalize, filter, and aggregate usage events or session records according to specific rules. The number of collectors in your deployment depends on the number and variety of data sources in your infrastructure and on the amount and type of preprocessing your business application needs.
The session server is the main component that implements the Real-Time Charging Manager. The Charging Manager 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 span multiple service offerings and charging methods. The session server is essentially a container that holds one or more connectors, one or more rule chains, and one or more session stores. You can configure as many session servers as you need, typically at least one for each protocol. In a highly available environment, you might have a second standby session server for each primary session server.
The configuration server maintains the configuration of every collector. It stores all of the configuration information in a central configuration store. Collectors retrieve their configuration from this configuration store when they start up. Applications that interact with collectors query the configuration server to get a collector’s CORBA address or IOR.
Present on each host in the deployment as either a Windows service or a UNIX daemon, the admin agent is the first IUM process to start. The admin agent then starts all other IUM processes on that host. It also communicates between the configuration server and the collectors.
IUM stores metadata and processed data in the SOLID embedded database. IUM also allows you to configure a pre-existing database, such as Oracle, instead.
Launchpad is a window interface that enables you create, modify, monitor and control collectors and other IUM processes and servers. It can be used to accomplish most development and maintenance tasks with IUM deployment, from implementation, configuration and testing to day-to-day monitoring and administration.
A special-purpose collector, a correlator reads usage data from usage collectors and session data from session collectors. It then combines these two sets of data, matching usage with users. For example, it may combine usage data from Cisco routers with session data from RADIUS sessions to associate network usage with corresponding users.
A special-purpose collector, a report collector obtains processed data from other collectors and stores the reporting-related information in the database.
A web application executed by the Tomcat servlet engine embedded in IUM, the Report Server is a Java process that obtains data from report collectors and prepares the reports for display. Schedule Server An optional process, the Schedule Server allows IUM (or external scripts) to perform specific operations at scheduled intervals.
Audit Report Server
A special-purpose collector, the Audit Report Server obtains audit information from other collectors and stores it in the database.
A collector consists three components:
- Encapsulator – reads the input data and places the data into a Normalized Metered Event or NME, the data record format used by all IUM components.
- Aggregator – processes the NME data.
- Datastore – stores the NME data and formats it for use by other collectors or applications.
Components of a Collector
© Copyright 2006 Hewlett-Packard Company
Any component can be replaced with another of the same type.
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:
- Solid Relational Database, included with IUM (The Solid database is a product of Solid InformationTechnology)
- Third-party relational databases such as Oracle
- IDR (Internet Data Record) files in HTML, XML, or plain text
- Our IUM Experience
ARTIN delivered solution using IUM for mobile carriers at home as well as abroad. We’ve got years of experience with complete development cycle starting with detailed request analysis, throught implementation and testing to deployment. IUM was used on projects for Orange SK (SDP Real-Time Charging interface), H3G Austria (FMC/RLC feeders, DPG support), Orange Romania (MMS mediation), HP Turkey and T-Mobile Czech republic (Data rating engine).