Elastic Charging Engine Cartridge Pack

4 Elastic Charging Engine Cartridge Pack

This document describes how to configure and use the Oracle Communications Offline Mediation Controller Elastic Charging Engine Cartridge Pack.

Topics in this document:

About the ECE Cartridge Pack

The ECE cartridge pack includes the ECE Distribution Cartridge (DC) node that enables Offline Mediation Controller to submit offline charging requests to ECE.

The ECE cartridge pack is used with the following existing cartridge packs to process the input records:

Simple ASCII
IMS
SGSN

Figure 4-1 shows the architecture of the ECE DC node.

Figure 4-1 ECE DC Node Configuration Architecture

Description of "Figure 4-1 ECE DC Node Configuration Architecture"

Integrating ECE and Offline Mediation Controller

Before using the ECE Cartridge Pack to create node chains, you need to configure ECE and Offline Mediation Controller to work together. The procedures differ depending on whether ECE and Offline Mediation Controller are installed on the same system.

Integrating When Offline Mediation Controller and ECE are on the Same System

To configure Offline Mediation Controller to support ECE when both are installed on the same system:

Open the OMC_home/bin/UDCEnvironment file in a text editor.
Set the IS_OCECE_REQUIRED parameter to true. This enables Offline Mediation Controller to interface with ECE.
```
IS_OCECE_REQUIRED=true
```
Set the OCECE_HOME_PATH parameter to the directory in which ECE is installed. For example:
```
OCECE_HOME_PATH=/home/opt/OracleCommunications/ECE
```
Save and close the file.
Start Offline Mediation Controller. See "Starting Offline Mediation Controller" in Offline Mediation Controller Installation Guide.

Integrating When ECE and Offline Mediation Controller are on Different Systems

To configure ECE and Offline Mediation Controller when they are installed on different systems:

Note:

Ensure that ECE is installed on a system within the same sub-network as the system on which Offline Mediation Controller is installed.

On the system where ECE is installed, open the ECE_home/oceceserver/config/charging-coherence-override-dev.xml file in a text editor, where ECE_home is the directory in which ECE is installed.

Uncomment the following element:

<well-known-addresses> 
    <socket-address id="1"> 
   <address system-property="tangosol.coherence.wka">localhost</address> 
   <port system-property="tangosol.coherence.wka.port">18088</port> 
    </socket-address> 
</well-known-addresses>

In the address element, replace localhost with the IP address of the system on which ECE is installed:
```
<address system-property="tangosol.coherence.wka">ip_address</address>
```

In the time-to-live element, set the value to 1:

<time-to-live system-property="tangosol.coherence.ttl">1</time-to-live>

In the cluster-name element, set the value to the ECE cluster name. For example:
```
<cluster-name system-property="tangosol.coherence.cluster">BRM</cluster-name>
```
Save and close the file.
Copy the ECE_home directory to the system where Offline Mediation Controller is installed.
On the system where Offline Mediation Controller is installed, open the OMC_home/bin/UDCEnvironment file in a text editor.
Set the IS_OCECE_REQUIRED parameter to true. This enables Offline Mediation Controller to interface with ECE.
```
IS_OCECE_REQUIRED=true
```
Set the OCECE_HOME_PATH parameter to the location of ECE_home on your Offline Mediation Controller system. For example:
```
OCECE_HOME_PATH=/home/opt/OracleCommunications/ECE
```
Save and close the file.
Start ECE in the system where ECE is installed.
Start Offline Mediation Controller. See "Starting Offline Mediation Controller" in Offline Mediation Controller Installation Guide.

Configuring the ECE DC Node

You send output to ECE by using the ECE DC node.

Table 4-1 shows the options to configure in the OCECE Configuration tab.

Table 4-1 OCECE Configuration Tab

Field	Description
Batch size	The number of records that will be submitted by OCOMC to ECE before waiting for responses. Larger batch sizes may help improve throughput. Larger batches may require the "Waiting time per batch" to be increased to permit all responses to be received from ECE before submitting the next batch.
Max records per suspense/success file	Maximum number of records per file written in the OMC_home/ocomc/suspense or the OMC_home/ocomc/success directory. The minimum value is 1 and the maximum value is 50000.
Waiting time per batch	Time in milliseconds the node waits for the batch to be processed. The minimum value is 1 and the maximum value is 1800000.
Timeout for Archiving NAR file	The frequency at which partially filled no-response, duplicate, and bad NAR records will be closed and moved to their corresponding destination locations. This permits partially filled files of failed NARs to be closed and moved (the max file size is controlled by the "OCECESuspenseBatchSize" configuration or, by default, will be 10000 records).
Response Timeout	The frequency with which the ECE DC Node will check for requests that have not received a response from ECE. The records are stored in memory until there is a response. Any record which has been waiting for a response for more than the "Response Timeout" will be written to the no-response NAR file. Note that as this parameter controls both the timeout and the frequency with which this check is executed, a no-response would be detected at latest two times the value of this timeout.
Request Throttling	In cases where the ECE server may not be responding as quickly as normal it can be helpful to pause submission of more work for a short time. When enabled, the number of outstanding requests will be checked after each batch and if larger than the "High-Water Mark", processing of the record stream will be halted until the number of outstanding requests drops below the "Low-Water Mark".
Output bad records as NAR	Generates a NAR for the bad records.
Log success records	Enables writing the records successfully processed by ECE to the file in the OMC_home/ocomc/success directory. The ECE DC node logs successfully processed ECE records to the success file when the advice of charge notification in ECE is set to include events such as an in-session notification on the usage response message (PIGGYBACK). See the ECE documentation for more information about configuring advice of charge notifications.
Submission-throttling milliseconds	Whilst "Request Throttling" controls submission at a batch level, the micro-throttling feature permits throttling of submission within a batch of records as a flow-control mechanism. If, at any time, the number of outstanding requests (those sent to the ECE server but for which responses have not been received) exceeds the "Max outstanding requests before throttling" configuration, the ECE DC Node will add a pause before submitting new requests to ECE. This configuration controls how long that pause will be (in milliseconds).
Max outstanding requests before throttling	Controls the maximum number of outstanding requests that will be permitted before the ECE DC Node begins pausing the submission of requests to ECE. See "Submission-throttling milliseconds" which defines how long each pause will be. Once the number of outstanding requests drops below this threshold, records will be submitted normally.
Max MSCC batch size	In cases where there are multiple input records in each batch that are for the same user identity, it is possible to group those records into a single request for the ECE server to permit them to be processed together. This can optimize throughput in cases where a large proportion of records are for a small number of distinct user identities. Typical values would be in the range of 1 to 10. There is generally little additional benefit from using larger batch sizes (and none in cases where all user identities are distinct).

Note:

By default, suspended CDRs are stored in the directory OMC_home/suspense. You can change the default directory using the Output Directory Configuration tab in the ECE DC node.

Table 4-2 shows the options to configure the output directories in ECE DC node along with their default configurations.

Table 4-2 Output Directory Configuration Tab

Field Name	Default Configuration
Duplicate request directory	OMC_home/output/nodeid/duplicate
Success response directory	OMC_home/output/nodeid/success
Susepense directory	OMC_home/suspense
No-response directory	OMC_home/output/nodeid/noresponse
Delayed response directory	OMC_homeoutput/nodeid/delayedresponse

Editing the ECE DC Rule File

When creating and configuring the ECE Distribution Cartridge (DC) node, you configure a rule file containing the mapping data from the network accounting record (NAR) format to an output format for use by ECE. For more information about editing rule files, see Offline Mediation Controller Cartridge Development Kit NPL Reference Guide.

When configuring the ECE DC node, define the following in the rule file:

Configuration Block

A configuration block is used to set configuration values that are needed by the node. You can define only one configuration block in an NPL rule file.

Syntax

Config {
PRODUCTTYPES "product_type[, ...]";
PAYLOAD "payload_type[, ...]";
PAYLOADDATATYPE "datatype";
USAGEOBJECTS "usage_object";
EVENT "event_type[, ...]";
VERSION "version_number[, ...]";
MODE "usage_request_mode";
TIME_ZONE "time_zone";
DATE_FORMAT "date_format";
USAGE_REQUEST_BUILDER "request_format";
}

Configuration Settings

PRODUCTTYPES "product_type[, ...]";

where product_type is a product type defined in ECE. This parameter is specific to the product types the ECE DC processes.

PAYLOAD "payload_type[, ...]";

where payload_type is the payload type defined in ECE.

PAYLOADDATATYPE "datatype";

where datatype specifies the data type used in payloads.

USAGEOBJECTS "usage_object";

where usage_object specifies the usage objects type. The default value is USAGEBUILDER.

EVENT "event_type[, ...]";

where event_type specifies the types of events. Add the event_type values separated by commas.

VERSION "version_number[, ...]";

where version_number specifies the version for each record corresponding to the product type. Add the version_number values separated by commas.

MODE "usage_request_mode";

where usage_request_mode specifies the mode in which Offline Mediation Controller sends usage requests to ECE. Set the parameter to one of the following values:

CUMULATIVE: Specifies that the balance impact in ECE is cumulative.
INCREMENTAL Specifies that the balance impact in ECE is incremental.

TIME_ZONE "time_zone";

where time_zone specifies the time zone used by the ECE DC node to send the session start time and the session end time to ECE. The default value is UTC. The time zone is set at record level or at cartridge level:

Record level: If the NPL output record block contains the timeZone field, the time zone is set at record level. For record level time zone, each call detail record (CDR) can have a different time zone defined by the timeZone field in the CDR.
Cartridge level: If the configuration block contains TIME_ZONE field, the time zone is set at cartridge level. All the CDRs processed by the cartridge will contain the same time zone as defined by the TIME_ZONE field.

Note:

If the time zone is defined at record level and at cartridge level, the record level time zone is used.

DATE_FORMAT "date_format";

where date_format specifies the date format used by ECE DC to send the session start time and the session end time to ECE. The default value is yyyy-MM-dd HH:mm:ss.

USAGE_REQUEST_BUILDER "request_format";

where request_format defines the usage request builders. This parameter creates the builders for the corresponding product type, event, and version.

For example:

Config {
PRODUCTTYPES "VOICE,DATA,SMS";
PAYLOAD "VOICE_USAGE_Terminate_PAYLOAD,VOICE_USAGE_Update_PAYLOAD,
VOICE_USAGE_Debit_unit_PAYLOAD,VOICE_USAGE_Refund_unit_PAYLOAD,
VOICE_USAGE_Refund_amount_PAYLOAD,VOICE_USAGE_Debit_amount_PAYLOAD,
DATA_DATA_USAGE_Terminate_PAYLOAD,DATA_DATA_USAGE_Update_PAYLOAD,
DATA_DATA_USAGE_Debit_unit_PAYLOAD,DATA_DATA_USAGE_Refund_unit_PAYLOAD,
DATA_DATA_USAGE_Refund_amount_PAYLOAD,DATA_USAGE_Debit_amount_PAYLOAD,
SMS_SMS_USAGE_Terminate_PAYLOAD,SMS_SMS_USAGE_Debit_unit_PAYLOAD,
SMS_SMS_USAGE_Refund_unit_PAYLOAD,SMS_SMS_USAGE_Refund_amount_PAYLOAD,
SMS_SMS_USAGE_Debit_amount_PAYLOAD";
PAYLOADDATATYPE "PAYLOADDATATYPE";
USAGEOBJECTS "USAGEBUILDER";
EVENT "USAGE,DATA_USAGE,SMS_USAGE";
VERSION "1.0";
MODE "CUMULATIVE";
TIME_ZONE "UTC";
DATE_FORMAT "yyyy-MM-dd HH:mm:ss";
USAGE_REQUEST_BUILDER "VOICE@USAGE@1.0,DATA@DATA_USAGE@1.0,SMS@SMS_USAGE@1.0";
}

Input Record Block

An input record block defines the fields in the input data record passed into the node.

Syntax

InputRec {
datatype parameter;
} in;

Where:

datatype is the data type of the input field; for example, String.

parameter is the input field name.

For example:

InputRec {
                String calling_number;
                Integer seq_no;
                Integer duration;
                String start_time;
                String product_type;
                String session_id;
                String CalledId;
                String end_time;
                String cell_id;
                String requestedInputVolume;
                String requestedOutputVolume;
                String requestedTotalVolume;
                String usedUnitsInputVolume;
                String usedUnitsOutputVolume;
                String usedUitsTotalVolume;
                String operationType;
                String correlation_identifier;
                String balance_element_id;
                String amount;    
              //  String timeZone;  
} in;

Output Record Block

An output record block is used to define the format of an output data record of the node.

Syntax

OutputRec {
datatype parameter;
} out;

Where:

datatype is the data type of the output field; for example, String.

parameter is the output field name.

For example:

OutputRec {
                String calling_number;
                Integer seq_no;
                String duration;
                String start_time;
                String end_time;
                String product_type;
                String session_id;
                String CalledId;
                String npl_type;
                String cdr_service;
                String cell_id;
                String requestedInputVolume;
                String requestedOutputVolume;
                String requestedTotalVolume;
                String usedUnitsInputVolume;
                String usedUnitsOutputVolume;
                String usedUitsTotalVolume;
                Integer usedUnitsSpecificUnit;
                String eventType;
                String version;
                String operationType;
                String correlation_identifier;
                Integer balance_element_id;
                Double amount;
                //  String timeZone;
} out;

Expose Block for PAYLOAD

For every payload type in the configuration block, define an Expose block. In the Expose block, map the NPL fields to the ECE Payload fields defined in the ECE request specifications.

For example:

Expose for VOICE_PAYLOAD{out.CalledId "CALLED_ID";out.duration "REQUESTED_UNITS[0].DURATION";}
Expose for DATA_PAYLOAD{out.cell_id "CELL_ID";
out.requestedInputVolume "REQUESTED_UNITS[0].INPUT_VOLUME";
out.requestedOutputVolume "REQUESTED_UNITS[0].OUTPUT_VOLUME";
out.requestedTotalVolume "REQUESTED_UNITS[0].TOTAL_VOLUME";
out.usedUnitsInputVolume "USED_UNITS[0].INPUT_VOLUME";
out.usedUnitsOutputVolume "USED_UNITS[0].OUTPUT_VOLUME";
out.usedUitsTotalVolume "USED_UNITS[0].TOTAL_VOLUME";}

Expose Block for Payload Data Type

For every payload data type in the configuration block, define an Expose block. In the Expose block, define the data type for the fields that are passed in the payload data type.

For example:

Expose for PAYLOADDATATYPE{out.duration "SECONDS";
out.requestedInputVolume "VOLUME";
out.requestedOutputVolume "VOLUME";
out.requestedTotalVolume "VOLUME";
out.usedUnitsInputVolume "VOLUME";
out.usedUnitsOutputVolume "VOLUME";
out.usedUitsTotalVolume "VOLUME";}

Expose Block for Usage Object

For every usage object type in the configuration block, define an Expose block. In the Expose block, map the NPL fields that are sent as parameters in the create usage objects method.

For example:

Expose for USAGEBUILDER{
out.calling_number "PARAM1";
out.session_id "PARAM2";
out.start_time "PARAM3";
out.end_time "PARAM4";
out.seq_no "PARAM5";
}

Mapping the Input Record Attribute to the Output Record Attribute

When mapping the input record attribute to the output record attribute, set the following output fields based on the specific product type for which the CDR is received:

cdr_service: Set this field to the product types for each CDR record.
eventType: Set this field to the event type for each CDR record corresponding to the product type.
version: Set this field to the version for each CDR record corresponding to the product type.
operationType: Set this field to the usage type for each CDR record corresponding to the product type.

See the sample mapping for the ECE cartridge pack in Offline Mediation Controller Cartridge Development Kit NPL Reference Guide for more information about the supported usage types.

For example:

out.cdr_service="VOICE"out.eventType="USAGE"out.version="1.0"out.operationType= "Terminate"

About Offline Mediation Controller Statistic Report and ECEDC Log

Offline Mediation Controller statistic reports (located at ocomc/adminsvr/statistics/reports) offer a high-level view of Call Detail Record (CDR) processing for various cartridges, detailing counts like incoming, outgoing, and discarded CDRs. However, ECEDC employs a dedicated log file for in-depth statistics. This log accumulates data from startup until restart and resides in the ocomcHome/log/<nodeId> directory. Analysing these statistics provides insights into received requests, rejections, submissions, response rates (including success, failure, and timeouts), and unprocessed records.

For error handling and missing response investigation, utilities like NARComparator and RatedEventsChecker can be employed. These tools help identify issues with reconciliation between the NoResponse and Delayed response NARs and aid in segregating records that needs to be resubmitted for usage processing.

The following is a sample statistics snippet that is printed in the cartridge log file:

Requests received : 3#EOR#
Requests rejected : 0#EOR#
Requests submitted : 3#EOR#
Responses sent by ECE : 3#EOR#
SUCCESS responses : 3 out of which 2 are DUPLICATE#EOR#
FAILURE responses : 0#EOR#
SUCCESS Delayed responses received 0 out of which 0 are DUPLICATE#EOR#
FAILURE Delayed responses received : 0#EOR#
No_Response records within the stipulated time : 0#EOR#