Rating CIBER Roaming Usage Events

10 Rating CIBER Roaming Usage Events

This chapter describes how to set up the Oracle Communications Billing and Revenue Management (BRM) Pipeline Manager for rating CIBER events.

About Processing CIBER OCC Records

Other charges and credits (OCC) records are CIBER records of types 50 and 52. When you configure a pipeline to create CIBER OCC records, one OCC record is generated for each day that a roaming subscriber makes one or more calls from a visited network. By default, a CIBER OCC record is created only for the first call processed for a subscriber for a particular day, with the day beginning at 12:00 a.m.

To generate CIBER OCC records for network operators, you configure the following components:

Use Pricing Center or Pipeline Configuration Center (PCC) to specify that CIBER OCC records are generated for network operators. See "About Generating CIBER OCC Records for Network Operators".
Configure the FCT_CiberOcc function module to create CIBER OCC records.

Use the EdrNetworkModel entry to specify the network model, which identifies the home network to use for the pipeline.
Configure the FCT_DuplicateCheck function module to set an EDR field for duplicate EDRs. This field is checked by the FCT_CiberOcc module to determine whether to create an OCC record.

Note:

To rate CIBER records, an EDR must be able to contain multiple charge packets. To enable this, create price models with multiple RUMs.

CIBER OCC records are created only when the call record being processed by FCT_CiberOcc has OCC-associated charges. The type of call record determines which OCC record type is generated as shown in Table 10-1:

Table 10-1 Call Record type

Call record type	Type of OCC record generated
10, 20, 30	50
22, 32	52
Other call records	No OCC record is generated.

If a combination of these types occur for a subscriber on the same day, the type of OCC record created is based on the first processed call record.

About Generating CIBER OCC Records for Network Operators

You use Pricing Center or Pipeline Configuration Center (PCC) to specify whether to generate CIBER records for other charges and credits (OCC records) during outcollect processing. These records let you apply surcharges when your partner's roaming customers make calls from your network.

Configuring Duplicate Check for CIBER OCC Records

You can avoid creating duplicate OCC records by configuring the FCT_CiberOcc module to work with the FCT_DuplicateCheck module.

Determine which field you want to use for duplicate check. Typically, this field is DETAIL.ASS_CIBER_EXT.NO_OCC. If you use a different field, it must be an Integer value.
Enter the field name in the FCT_CiberOcc module NoOCCField registry entry:
```
NoOCCField = DETAIL.ASS_CIBER_EXT.NO_OCC
```
Enter the same field name in the FCT_DuplicateCheck module DuplicateIndicatorField registry entry:
```
DuplicateIndicatorField = DETAIL.ASS_CIBER_EXT.NO_OCC
```

Changing the Default Time Scheme

A CIBER OCC record is generated only for the first call processed for a subscriber for the day, with the day beginning at 12:00 a.m. You can customize this feature to use another time scheme for all system identification numbers (SIDs). However, you cannot specify different time schemes for different SIDs.

To use another time scheme:

Define a new EDR field that records an attribute of the call date and time.

This field will be used to determine whether to generate an OCC record. For example, record a value between 1 and 12 to generate an OCC record once per month, or record a value between 1 and 52 to generate a weekly OCC record.
Write an iScript that sets a value in the new EDR field based on the call date. This iScript must be executed in the pipeline before the FCT_DuplicateCheck module.
Specify the new EDR field for duplicate checking in the Fields entry in the FCT_DuplicateCheck module registry.
Specify the values that describe the new time interval in the OCCIntervalIndicator and OCCDescription entries in the FCT_CiberOcc module registry.
- The OCCDescription entry specifies the service associated with the OCC.
  
  This value is entered in the OCC_DESCRIPTION field in the ASSOCIATED_CIBER_EXTENSION block of the OCC record created.
  
  Note:
  
  This field must not contain spaces. If you require spaces in the description, write an iScript to populate this field.
- The OCCIntervalIndicator field specifies the interval at which the associated OCC record is generated.
  
  Note:
  
  To use an interval other than the default (daily), you must customize this feature. See "Changing the Default Time Scheme".
  
  Possible values:
  
  1 = Event (Generates an OCC record based on an event.)
  
  2 = Hourly
  
  3 = Daily
  
  4 = Weekly
  
  5 = Monthly
  
  This value is entered in the OCC_INTERVAL_INDICATOR field in the ASSOCIATED_CIBER_EXTENSION block of the OCC record.
Change the DETAIL.ASS_CIBER_EXT.OCC_END_DATE field in the OCC record to the date or time specific to your needs. By default, this field is set to the value of OCC_START_DATE to apply a daily surcharge.

Note:

You can change the field by writing an iScript.

About Finding the Charge for CIBER Records

To ensure that a charge is selected for every CIBER record, you must define a default Interconnect (IC) charge offer for source networks. IC charge offers are linked to charges. If a search for a corresponding charge cannot be found for the source network, the charge for the default IC charge offer is used.

You configure IC charge offers in Pricing Center or Pipeline Configuration Center (PCC).

For every IC charge offer Configuration that has a value in the Source Network entry, add a new IC charge offer Configuration.

Configuring EDR Field Validation

You configure an EDR field validation to ensure that your roaming partner has followed the agreed procedure for generating files and automatically return the single EDRs that do not match the agreement, without rejecting the entire file.

To perform EDR field validation, follow these procedures:

Configure the "ISC_CiberInputValidation" iScript to validate CIBER record fields.
Configure the iRuleValidation iRule module to validate CIBER record fields. See "Configuring the iRuleValidation Module".

To perform additional EDR field validation, configure rule sets and assign the rule sets to the FCT_IRules module. See "Configuring Rule Sets for the EDR Field Validation".

Configuring the iRuleValidation Module

The iRuleValidation module is an instance of the FCT_IRules function module. To configure iRuleValidation, set up an instance of FCT_IRules in the FunctionPool section of the Pipeline Manager registry and use iRulesValidation as the module instance.

iRuleValidation uses one of the following XML files that contain the rules and rule sets used for validation:

The CIBER_VAL.xml file specifies the rules and rule items for CIBER records.

Rules in the .xml file must be loaded into the Pipeline Manager database before starting a pipeline.

Specify the XML rules file in the Rules entry of the iRuleValidation registry.

Configuring Rule Sets for the EDR Field Validation

You configure rule sets for EDR field validation in the database. You name a rule set according to the format used, such as CIBER. Each rule set consists of a series of rules, defining one rule for each of the EDR fields that are validated. Each rule contains a rule item. This rule item represents the current default error condition that results in an error message.

There are several levels of error messages:

Severe errors
Fatal errors
Warning errors

Note:

In case of warning errors, Pipeline Manager generates an internal error that is logged in the stream log but does not return any detail. In this case, you discuss the settlement with your roaming partner using a conventional method, such as telephone or mail.

The rules and rule sets for EDR field validation are stored in the following database tables:

IFW_RULESET
IFW_RULESETLIST
IFW_RULE
IFW_RULEITEM

You can use the following tools to configure rules and rule sets:

Pricing Center or Pipeline Configuration Center (PCC).
The FCT_IRules module. This module can use rules stored in the database.