1 Overview of Offline Mediation Controller

Learn about Oracle Communications Offline Mediation Controller.

Topics in this document:

• About Offline Mediation Controller

• Offline Mediation Controller System Architecture

About Offline Mediation Controller

Offline Mediation Controller is a mediation application for communications services, such as wireless voice and data, content downloads, and voice over IP (VoIP). Offline Mediation Controller receives data from network devices, normalizes and transforms it, and sends it to systems and applications such as Oracle Communications Elastic Charging Engine (ECE).

Offline Mediation Controller processes data to support services such as:

• Wireless: GSM, GPRS, CDMA

• VoIP

• IP

Offline Mediation Controller sends data to systems and applications such as:

• Charging and billing systems

• Performance Management and Service Quality Management systems

• Inventory systems

Offline Mediation Controller receives input from a network device and translates the data into network accounting records (NARs). A NAR uses an internal format that is used by all Offline Mediation Controller components. A NAR can contain information used for charging, such as the calling number, called number, origin, event start time, event end time, amount of data downloaded, IP address, and so on.

Offline Mediation Controller collects data from the source application or the network, normalizes the data to NAR format, and then processes and prepares it for one or more downstream systems.

Figure 1-1 shows the Offline Mediation Controller work flow.

Figure 1-1 Offline Mediation Controller Work Flow

Description of "Figure 1-1 Offline Mediation Controller Work Flow"

Processing is performed by four types of nodes:

• Collection cartridge (CC). CC nodes collect raw data from devices outside if the Offline Mediation Controller system and transforms the data into NARs that can be processed by Offline Mediation Controller.

• Enhancement processor (EP). EP nodes add, modify, or delete data in NARs. For example, an EP node can add data based on IP ports, or source and destination IP addresses detected in incoming NARs. You can also use the EP node to enhance NARs with information from outside of the Offline Mediation Controller system.

• Aggregation processor (AP). AP nodes aggregate data and records. For example, long-duration sessions can be received in multiple call detail records (CDRs). You can use the AP node to aggregate the CDRs into one NAR file.

• Distribution cartridge (DC). DC nodes distribute the network data collected and processed by other functional nodes. The DC node converts NAR files to a specified output format and moves the resulting files to its output queue.

You add these nodes to a node chain. The first node is always a CC node, and the last node is always a DC node. The processing nodes (EP and AP) are optional, and can be in any order. You typically use multiple EP nodes for different types of processing, such as mapping, normalizing, and so on.

Figure 1-2 shows a sample node chain that processes GPRS events for Elastic Charging Engine.

Figure 1-2 Node Chain

Description of "Figure 1-2 Node Chain"

In this example:

• The CC node reads GPRS records and transforms them into NARs.

• The EP nodes perform normalization and record sequencing to ensure that events are processed correctly.

• The AP node aggregates partial records into a single record.

• The DC node sends the NARs to the Elastic Charging Engine.

Depending on your service offerings, you can create multiple node chains that handle different types of input, and provide output to the same system. Figure 1-3 shows a typical configuration for receiving input from ASCII, IMS, and SGSN, and providing output to Elastic Charging Engine.

Figure 1-3 Multiple Node Chains

Description of "Figure 1-3 Multiple Node Chains"

To create a node chain, you configure the nodes that are required to process events for a particular input and output; for example, a node chain that processes wireless events to send to ECE. When you configure each node, you work with two aspects of the node:

• Node configuration: This specifies how the node functions in the node chain. For example, when defining the node configuration for an EP node that checks for duplicate records, you specify the directory that holds duplicate records, the number of records in a duplicate-record file, and the next node in the node chain.

• Rule file: This defines how the node handles each record and carries out its work. For example, a rule file for an EP node that checks for duplicate records defines the field in the record that is used for detecting duplicate records, such as the calling number or session ID.

Offline Mediation Controller includes predefined nodes and rule files to support specific communication services: wireless, IP, and VoIP. When you create a node, you start by choosing the solution you are delivering (as shown in Figure 1-4), or you can choose a cartridge kit that is independent of a solution.

Figure 1-4 Selecting a Service Solution

Description of "Figure 1-4 Selecting a Service Solution"

Each solution includes a set of solution-specific nodes and rule files to choose from. For example, to configure a node chain for wireless events, you can use predefined EP nodes for processing ASN data, CDR sequence management, and record filtering.

• For wireless services, Offline Mediation Controller delivers the Charging Gateway Functionality (CGF) as specified by the 3GPP for wireless GSM/GPRS/UMTS networks. It goes beyond the basic CGF by supporting numerous applications and services.

• For IP services, Offline Mediation Controller includes pre-integrated support for numerous industry-leading routers, switches, and IP service platforms. Raw service and network usage data is collected, aggregated, and enhanced with QoS and customer-specific information.

• For VoIP services, Offline Mediation Controller supports next generation VoIP telephony platforms as well as legacy protocols and record formats, enabling migration from legacy voice networks to VoIP.

In addition to solution-based nodes and rule files, you can use application-specific cartridges. Cartridges include specialized nodes and rule files. For example:

• Use the Oracle CDR Format cartridge to configure a CC node when you integrate Offline Mediation Controller with Oracle Communications Billing and Revenue Management (BRM).

• Use the suspense and recycle nodes to integrate Offline Mediation Controller with BRM Suspense Manager.

After you install a cartridge, the nodes in the cartridge are available in the Administration Client. Figure 1-5 shows how node types are organized by domain (wireless, and so on) and by type (CC, EP, and so on). In this figure, the OCECE DC node is present, indicating that the ECE Cartridge Pack has been installed.

Figure 1-5 Available Node Types in Administration Client

Description of "Figure 1-5 Available Node Types in Administration Client"

Cartridges are installed as JAR files. Each cartridge supports a specific domain of functional area. You can use the Cartridge Development Kit (CDK) to create custom cartridges that support input from new network elements, or can output records to custom systems and applications.

Offline Mediation Controller System Architecture

Offline Mediation Controller include three main components:

• Node managers run the nodes in node chains.

• The administration server runs the node managers, and manages all of the Offline Mediation Controller processes.

• You configure node chains and administer the system by using the Administration Client.

To run Offline Mediation Controller, you start all three components. You can also start and run individual nodes.

Figure 1-6 shows the Offline Mediation Controller system architecture.

Figure 1-6 Offline Mediation Controller System Architecture

Description of "Figure 1-6 Offline Mediation Controller System Architecture"

In Figure 1-6:

• Administration Client is a GUI application that you use for creating node chains and editing rule files. You also use Administration Client for administrating Offline Mediation Controller. For example, you can use it to manage users and define instances of system components.

• The administration server is a process that passes commands between Administration Client and the node managers, which in turn control the nodes. The administration server manages log files and manages the data flow in the entire Offline Mediation Controller system. You can run one primary administration server and one backup administration server.

• A mediation host is a server on which nodes and node managers run:

  • Node managers run the nodes in a node chain. You send commands to a node manager to stop and start nodes.

  • Local data managers pass data from one node to another on the same mediation host.

  • Remote data managers pass data from a node on one mediation host to a node on a different mediation host.

  A mediation host is not a component that runs. You do not stop and start a mediation host. Instead, it provides a location on the system where nodes and node managers can run. You typically configure multiple mediation hosts to distribute processing.

• Oracle Unified Directory manages Offline Mediation Controller users.

• The optional SNMP trap host is an IP host that receives SNMP trap messages from the Offline Mediation Controller system. Offline Mediation Controller issues SNMP trap messages to send alarms to network management systems.

Offline Mediation Controller is typically distributed on multiple systems. You can run one or more administration servers, and each administration server connects to node managers hosted on multiple meditation host systems. Figure 1-7 shows a configuration with multiple mediation hosts and node managers. Using multiple mediation hosts enables more efficient use of system resources and improves performance.

Figure 1-7 Distributed Processing on Two Mediation Hosts

Description of "Figure 1-7 Distributed Processing on Two Mediation Hosts"