About Pipeline Rating

17 About Pipeline Rating

This chapter provides an overview of how to use the Oracle Communications Billing and Revenue Management (BRM) Pipeline Manager to rate usage events.

Topics in this document:

About Batch Rating

Batch rating is typically used for rating telephony services, where large amounts of events are recorded in files. Batch rating is usually performed by Pipeline Manager, but you can also perform batch rating by using Universal Event (UE) Loader.

For example, to rate telephone calls:

Pipeline Manager reads the data from CDRs to determine the time and duration of the calls.
Pipeline Manager rating modules apply a charge to the amount of time. For example, if you specify a charge of 10 cents per minute, a 10-minute call costs $1. This charge is called the balance impact.
Rated Event (RE) Loader loads the rated events into the BRM database.
BRM adds the total charge for the event to the customer's account balance.

Figure 17-1 shows how a billable event is rated by Pipeline Manager and recorded in the BRM database:

Figure 17-1 Pipeline Manager Event Rating and Recording to BRM Database

Description of "Figure 17-1 Pipeline Manager Event Rating and Recording to BRM Database"

How Events Are Rated by Using Pipeline Manager

Pipeline Manager rates only usage events, not recurring events, and not one-time events. Pipeline Manager rates usage events as follows:

Call detail record (CDR) files are collected from network switches and processed by mediation software. The mediation software converts data into the Oracle CDR format so it can be read by a pipeline input module. See "About the Oracle CDR Format".

Mediation can also remove records that are not needed for rating. For example, it can remove records for free text messages reminding customers of a missed call.
The mediation software places the CDR file in a predefined directory.
The pipeline input module reads the CDR file and begins processing it. The input module does the following:
- Performs error checking on the input CDR.
- Converts the data in the CDR file into event data records (EDRs). To do so, the input module normalizes the raw data that represents each event and formats it into a standard structure that can be processed by the pipeline modules.
Function modules, working with data modules, rate the events.
- Function modules perform the preprocessing and rating operations. For example, they check for duplicated EDRs, determine the quantity to rate, the zone to apply, and the charge for the event.
- Data modules supply data to the function modules by reading from the Pipeline Manager database or the BRM database.
The output module writes data to an output file.
Rated Event (RE) Loader reads the output file, loads the events into the BRM database, and updates the customer's account balance.

Figure 17-2 shows how usage events are rated:

Figure 17-2 Usage Events Rating

Description of "Figure 17-2 Usage Events Rating"

When you configure Pipeline Manager, you do the following:

Configure the input module to accept and process your type of CDR file.
Configure function and data modules to carry out normalization, zone mapping, and rating.
Configure the output module to output the data.

In addition to configuring Pipeline Manager, you need to do the following:

Configure the Account Synchronization Data Manager (DM) to transfer data from the BRM database to Pipeline Manager.
Configure RE Loader to load rated events into the BRM database. See "Understanding Rated Event Loader".

How an EDR Is Processed in a Pipeline

When an EDR is sent through a pipeline, function modules perform the following types of operations:

The input module processes the CDR and creates an event data record (EDR) for each event. Processing the CDR file includes:
- Identifying each type of record in the file; for example, header records, event records, and trailer records.
- Normalizing data and translating it into the internal EDR format.
Preprocessing modules prepare EDRs for rating. For example:
- The FCT_DuplicateCheck module discards duplicate EDRs.
- The FCT_CallAssembling module assembles calls that have been split into multiple records.
- The FCT_Reject module rejects EDRs with errors.
Preprocessing modules typically run at the beginning of a pipeline.
Enrichment modules normalize or add data that the rating modules need. For example:
- The FCT_ServiceCodeMap module assigns an internal service code to identify which service generated the event.
- The FCT_CliMapping module maps multiple phone numbers to a single phone number, so customers can be billed for all of their phones on one bill.
Enrichment modules typically run before rating modules in a pipeline.
Zoning modules calculate geographic or area-code-based zones for rating purposes.
Rating modules perform rating.
Discount modules perform discounting, after the EDR has been rated.
The aggregation module collects data for reports.

About the Order of Modules in a Pipeline

Some modules need to be configured in a specific order. For example:

You use the FCT_Discard module to discard EDRs that you don't want to rate. You need to discard them before the rating modules process them; otherwise you spend system resources on rating unwanted EDRs.
To provide discounts, the discount module needs to work with events that have already been processed by the rating modules.

For information about the order of modules in a pipeline, see "Function Module Dependencies".

About the Oracle CDR Format

The Oracle CDR format is the standard CDR file format used by Pipeline Manager for processing CDRs. For example, the Oracle CDR format is used by pipelines to generate CDRs that are passed between pipelines for additional processing, such as between a preprocessing pipeline and a rating pipeline.

The Oracle CDR format can also be used as the input format for rating pipelines. Additionally, pipelines can be configured to translate other formats into the Oracle CDR format for rating.

For complete details about the Oracle CDR format structure, see "BRM Rating EDR Container Description".

For information about the input and output processes, see "Configuring EDR Input Processing" and "Configuring EDR Output Processing".

About EDRs

The data for each event is stored as an EDR. As an EDR is processed, function modules process data in it or add data. For example, the FCT_CustomerRating module adds the charge code. The FCT_MainRating module uses that code to calculate and add the charge amount.

The following sample shows a portion of a charge packet in an EDR. Each field stores a specific piece of data; for example, the RATEPLAN_CODE field stores the charge used for rating the event.

CHARGE_PACKET
RATEPLAN_CODE:               <SIMPLERATE>
RATEPLAN_TYPE:               <R>
ZONEMODEL_CODE:              <MT_ZM>
SERVICE_CODE_USED:           <SMS>
SERVICE_CLASS_USED:          <DEF>
IMPACT_CATEGORY:             <MT_SMS>
TIMEMODEL_CODE:              <TM_MTEL>
TIMEZONE_CODE:               <TZ_WKNDDT>
DAY_CODE:                    <WEEKEND>
TIME_INTERVAL_CODE:          <0800_2000>
PRICEMODEL_CODE:             <MT_SMS>
PRICEMODEL_TYPE:             <S>
RESOURCE:                    <YEN>
RUMGROUP:                    <EVENT>
RUM:                         <EVT>
CHARGE_TYPE:                 <N>
CHARGING_START_TIMESTAMP:    <20020901182200>
CHARGEABLE_QUANTITY_VALUE:   <1>
CHARGED_CURRENCY_TYPE:       <R>
CHARGED_AMOUNT_VALUE:        <50>
CHARGED_AMOUNT_CURRENCY:     <JPY>
CHARGED_TAX_TREATMENT:       <N>
CHARGED_TAX_RATE:            <0>
CHARGED_TAX_CODE:            <NORM>
USAGE_GL_ACCOUNT_CODE:       <50000>

About EDR Containers

EDR containers are temporary in-memory data structures for transporting EDRs through function modules. Each container stores data for a header record, a detail record, or a trailer record.

When a transaction starts:

The EDR Factory creates an EDR container according to the information in the container description file.
The input module writes data to relevant fields in the container. For more information, see "Configuring EDR Input Processing".
The function modules process data in or add data to particular fields. For example, the FCT_BillingRecord function module processes balance impact-related data.
The EDR Factory empties the container and releases the cache, which will be used for other containers.

About the EDR Container Description

The data in an EDR, the default values, and the way the data is organized are defined in a container description. A typical container description defines the following types of containers:

A header container type. The header container type contains information stored in a header record; for example, the country of origin, originating network, and creation time. It also includes sequence numbers for ensuring that EDRs are processed correctly. A separate EDR is created for the header record.
One or more basic detail container types. A basic detail container includes the data in an event record; for example, a phone call. This record includes information such as the A number and the service that generated the event. An EDR is created for each detail record. Each EDR can contain data for one service only; for example, GSM or GPRS.

Each detail record includes one or more associated records. These records include service-specific data, zoning data, and rating data. See "About Associated Records".
A trailer container type. The trailer container type contains information stored in a trailer record; for example, the number of records. A separate EDR is created for the trailer record.

In almost all cases, you can use the BRM EDR container description. You can also customize the data that is included in an EDR by customizing the container description.

Note:

If you customize the container description, you need to make sure that your customizations do not affect existing module functionality. For example, many modules require data from a specific EDR field.

About the Container Description File

The container description file is an ASCII file that defines how to build EDR containers. You use the file to define the data in the EDR container, the default values, and the way the data is organized. For more information, see "About the EDR Container Description".

The default container description file is pipeline_home/formatDesc/Portal/containerDesc.dsc, where pipeline_home is the directory in which you installed Pipeline Manager. This file covers the needs of most input file formats, but you can customize it to meet your business requirements.

Note:

If you alter or add fields to the container description file, you may also need to write custom iScripts to access these new fields.

Figure 17-3 shows the BRM EDR container organization:

Figure 17-3 BRM EDR Container Organization

Description of "Figure 17-3 BRM EDR Container Organization"

About Associated Records

Associated records are added to EDRs by different modules; for example, the FCT_SegZoneNoCust module adds an associated zone breakdown record.

Associated service extension record. This record stores specific information about the service that generated the event; for example, the originating switch and the device number.

EDRs for GSM events can include one or more service event records. This record includes event information, such as equipment used and details about supplementary services.
Associated BRM billing record. This record stores rated event data that is loaded into the BRM database. It includes the POID of the /account object and /service object and the POID of the item that receives the balance impact. This record is created by the FCT_BillingRecord module.

If an event affects more than one customer balance, an associated BRM billing record is created for each balance.

An associated BRM billing record can contain one or more balance impact packets. These contain data about the event. Each balance impact packet includes data for one balance impact per balance element, and, optionally, per G/L ID.
Associated charge breakdown record. These records hold the charges for an event. For example, the FCT_CustomerRating module adds an associated charge breakdown record to the EDR to record the rating results.

Each associated charge breakdown record includes one or more charge packets. Each charge packet includes a single charge; for example, the charge for a telephone call for a single time period.

Each charge packet can include one or more discount packets. A discount packet includes information about the discount owner and rollover information.

During rating, Pipeline Manager might generate several charge packets. For example:
- When rating multiple balance elements, each balance element has its own charge packet.
- When using multiple ratable usage metrics (RUMs), each RUM has its own charge packet.
- When splitting charges across time zones, each time zone has its own charge packet.
- If multiple currencies are used, each currency has its own charge packet.
Associated zone breakdown record. This record contains data for zoning. It is created by the FCT_SegZoneNoCust module. This is used for comparative analysis of different zoning options.

An associated zone breakdown record includes one or more zone packet records. Each of these records includes data about a single zone model.
Associated message description record. This record holds information and error messages.

How an Input File Is Represented in EDR Containers

A typical conversion from an input file to EDR containers creates the following EDRs:

A set of control EDRs that the pipeline uses for managing transactions. For example, this control EDR specifies to start a transaction:

= = = = =  S T A R T    O F    C O N T A I N E R  = = = = = 
Container type = <SERVICE>
Content type   = <BEGIN_TRANSACTION>
Originator     = <ifw.Pipelines.W_SAMPLE.Input>
Stream Number  = <0>
IsValidDetail  = <false>
Record number  = <1>
has Errors     = <0>
.
.
.
= = = = = =  E N D    O F    C O N T A I N E R  = = = = = =

A header record that includes information about the input file:

= = = = =  S T A R T    O F    C O N T A I N E R  = = = = = 
Container type = <DATA>
Content type   = <HEADER>
Originator     = <>
Stream Number  = <3>
IsValidDetail  = <false>
Record number  = <0>
has Errors     = <0>

HEADER
------

RECORD_LENGTH:                      <0>
RECORD_TYPE:                        <>
RECORD_NUMBER:                      <0>
.
.
.
= = = = = =  E N D    O F    C O N T A I N E R  = = = = = =

Multiple detail records, each containing the data for one event:

= = = = =  S T A R T    O F    C O N T A I N E R  = = = = = 
Container type = <DATA>
Content type   = <DETAIL>
Originator     = <>
Stream Number  = <3>
IsValidDetail  = <true>
Record number  = <1>
has Errors     = <0>

DETAIL
------

RECORD_LENGTH:                      <0>
RECORD_TYPE:                        <020>
RECORD_NUMBER:                      <0>
DISCARDING:                         <0>
TYPE_OF_A_IDENTIFICATION:           <S>
A_MODIFICATION_INDICATOR:           <00>
A_TYPE_OF_NUMBER:                   <0>
A_NUMBERING_PLAN:                   <0>
A_NUMBER:                           <008190115551212>
.
.
.
= = = = = =  E N D    O F    C O N T A I N E R  = = = = = =

A trailer record, which includes information about the records in the file:

= = = = =  S T A R T    O F    C O N T A I N E R  = = = = = 
Container type = <DATA>
Content type   = <TRAILER>
Originator     = <>
Stream Number  = <3>
IsValidDetail  = <false>
Record number  = <7>
has Errors     = <0>

TRAILER
-------

RECORD_LENGTH:                      <0>
RECORD_TYPE:                        <090>
RECORD_NUMBER:                      <14>
.
.
.
= = = = = =  E N D    O F    C O N T A I N E R  = = = = = =

A set of control EDRs. This EDR specifies the end of a transaction:

= = = = =  S T A R T    O F    C O N T A I N E R  = = = = = 
Container type = <SERVICE>
Content type   = <END_TRANSACTION>
Originator     = <ifw.Pipelines.W_SAMPLE.Input>
Stream Number  = <0>
IsValidDetail  = <false>
Record number  = <8>
has Errors     = <0>
.
.
.
= = = = = =  E N D    O F    C O N T A I N E R  = = = = = =

How EDRs Are Used for Managing Transactions

Transactions are managed by using the EDR content type:

When an EDR with the BEGIN_TRANSACTION content type is processed, a new transaction is started. This usually occurs at the beginning of each input file.
When an EDR with the END_TRANSACTION content type is processed, the transaction is ended. This usually occurs at the end of each input file.
When an EDR with the STOP content type is processed, this indicates that the pipeline is shutting down gracefully and gives the modules a chance to save their state and prepare for the shutdown.

About Mapping EDR Field Names and Alias Names

The EDR container description defines the data in the EDRs and the name of each field. See "About the EDR Container Description".

In the pipeline modules, EDR fields can optionally be represented using two names:

The EDR container field name; for example, DETAIL.RECORD_LENGTH. This is the input format of the field.
An alias name, to which the container field name is mapped; for example, BDR_RECORD_LENGTH.

The sample below shows EDR container field names on the left and internal alias names on the right:

DETAIL.RECORD_LENGTH     ->  BDR_RECORD_LENGTH
DETAIL.RECORD_TYPE       ->  BDR_RECORD_TYPE
DETAIL.RECORD_NUMBER     ->  BDR_RECORD_NUMBER
DETAIL.DISCARDING        ->  DISCARDING
DETAIL.CHAIN_REFERENCE   ->  CHAIN_REFERENCE

Pipeline Manager function modules and iScripts use the alias name for manipulating data. When you write a custom iRule or an iScript, you must create an alias name for the EDR container fields that your module uses. Using alias names facilitates customization because you can use the container fields with different names and hierarchies without the need to change the module source code. See "Viewing and Creating Alias Mapping for an EDR Field".

Note:

The same EDR container field can be mapped to different alias names in different modules.

The list of BRM-defined alias names is in pipeline_home/formatDesc/Portal/AliasFieldList.dsc.

Viewing and Creating Alias Mapping for an EDR Field

Use Pricing Center or Pipeline Configuration Center (PCC) to view a list of existing alias mappings and to add custom alias mappings.

The Alias Mapping table lists the existing alias names including the BRM-defined alias names. Each entry includes the following mapping information:

EDR Container Description, which specifies the EDR container to which the EDR field belongs.
Reference, which is the pipeline module that uses the alias name. Its value is the pipeline module reference in the module block of the pipeline registry file; for example, PipelineSplit in the following registry entry:
```
PipelineSplit 
{
   ModuleName = FCT_IRules
   Module 
  {
    … 
   }
} 
```
Note:

If the value of Reference is Account_CustA, Account_CustB, UniData_CustA, or UniData_CustB, the alias mapping table entry defines the EDR field from which to get the account identifier. If the value is RUM, the alias mapping defines the EDR field from which to get the rateable usage metrics (RUM) quantity. If the value is UOM, the alias mapping defines the EDR field from which to get the unit of measure for a RUM
Key, which is the alias name for the EDR container field.

Note:

For Account_CustA, Account_CustB, UniData_CustA, and UniData_CustB, this is the service code.
Type, which is Internal for the alias mappings used by the default pipeline modules and Plugin for the modules used by custom modules.
Field ID, which is the name of the field in the EDR container.
History, which specifies when the alias mapping was created or modified.

About Function Modules

Function modules perform all the rating tasks in a pipeline. In addition, they perform EDR management tasks, such as ensuring that duplicate EDRs aren't processed.

There are different categories of function modules. They generally run in the following order:

Preprocessing modules prepare EDRs for rating. See "About Preprocessing Modules".
Enrichment modules add data to EDRs. See "About Enrichment Modules".
Service mapping modules map external service codes to internal service codes. See "About Service Mapping Modules".
Zoning modules calculate zone data to use for rating. See "About Zoning Modules".
Rating modules rate the events. See "About Rating Modules".
Discount modules adjust the charges. See "About Discounting Modules".
Roaming modules are specialized zoning and rating modules that handle roaming events. See "About Roaming Modules".

About Preprocessing Modules

Use the preprocessing modules to handle the following tasks:

Use the "FCT_CallAssembling" module to assemble calls that have been split into multiple EDRs. See "Assembling EDRs".
Use the "FCT_Reject", "FCT_PreSuspense", and "FCT_Suspense" modules to handle EDRs that contain errors. Rejected EDRs are sent to a separate output stream. You can then fix the problem that caused them to be rejected and re-process them. See "Suspending and Recycling EDRs".
Use the "FCT_DuplicateCheck" module to discard duplicate EDRs. See "Handling Duplicate EDRs".
Use the "FCT_Discard" module to discard EDRs that you don't want to process. See "Discarding and Skipping EDRs".
Use the "FCT_EnhancedSplitting" module to send EDRs to different output streams based on rules that you define. For example, you can split EDRs from roaming outcollects and incollects into different streams. See "Using Rules to Send EDRs to Different Output Streams".
Use the "IRL_EventTypeSplitting" iRule to send EDRs to different output streams based on the service. See "Sending EDRs to Pipeline Output Streams".
Use the "FCT_AccountRouter" to send EDRs to the correct pipeline in a multischema system. See "Using Pipeline Manager with Multiple Database Schemas".

You set up EDR preprocessing by configuring modules in a pipeline. For information on configuring preprocessing modules, see "Configuring EDR Preprocessing".

About Enrichment Modules

When you enrich EDR data, you add or change data for further processing.

Use the "FCT_CliMapping" module to specify that multiple phone numbers owned by one customer are charged for on one bill. See "Mapping Multiple Phone Numbers to a Single Number".
Use the "FCT_SocialNo" module to identify "social numbers" that are not displayed on an invoice. See "Setting Up Social Numbers".
Use the "FCT_NOSP" module to identify a network operator and service provider when performing segment rating. See "Identifying the Network Operator/Service Provider".
Use the "FCT_NumberPortability" module to process events correctly when a customer changes network provider but keeps the phone number. See "Setting Up Number Portability".
Use the "FCT_PrefixDesc" module to specify how to identify the destination of a call based on the number prefix. See "Creating Call Destination Descriptions".

You set up EDR enrichment by configuring modules in a pipeline. For more information about enrichment modules, see "Setting Up EDR Enrichment".

About Service Mapping Modules

Incoming EDRs from multiple switches often use different codes to represent the same service or supplementary service. To process EDRs, you need to normalize that data by mapping external service codes to internal service codes, service classes, and usage classes. You use the following modules:

Use the "FCT_ServiceCodeMap" module to map external service codes to internal service codes. For example, CDRs might use different codes for different types of telephony services. You can map those codes to a single code; for example, TEL. The service is typically a bearer or primary service.
Use the "FCT_UsageClassMap" module to map external codes for supplementary services, such as call forwarding, to internal usage classes. Usage classes are typically used for rating based on quality of service, sub-services, or service-level agreement values.
Use the "IRL_UsageType" iScript to assign usage types to EDRs. A usage type is an internal code that represents an attribute of a customer account; for example, a friends and family discount.
Use the "FCT_UoM_Map" module to convert the unit of measurement (UoM) of an incoming EDR to a UoM needed for rating a particular service. For example, an EDR might include the usage amount in seconds, but the service is configured to charge by minutes. The FCT_UoM_Map module converts seconds to minutes, using rounding rules.

You configure service mapping by configuring mapping modules in a pipeline.

About Zoning Modules

Zoning function modules prepare EDRs for rating by identifying geographic or logical zones that are used for rating.

You can identify zones as follows:

Using logical source and destination; for example, area codes, the service used, or retail or wholesale usage.
Using geographic distance.

Zoning is performed by the following function modules:

Use the "FCT_PreRating" module to calculate zones and impact categories.
Use the "FCT_APN_Map" module to process APN data for zoning.
Use the "FCT_USC_Map" module to refine impact categories based on service attributes.
Use the "FCT_Zone" module to compute zones when you use a pipeline only for zoning.

About Rating Modules

Rating modules rate EDRs. Each module performs a specific function; for example, the FCT_Dayrate module determines the time of day used for rating. Because each module adds or modifies data, the order of modules is important. For example, the FCT_RateAdjust module must process EDRs after the FCT_MainRating module. For more information, see "Function Module Dependencies".

Use the "FCT_GlobalRating" module to apply a global charge to all EDRs.
Use the "FCT_CustomerRating" module to provide customer data for other rating modules.
Use the "FCT_RSC_Map" module to perform rating based on the quality of service when you set up service-level agreements (SLAs).
Use the "FCT_RateAdjust" module to adjust charges after rating.
Use the "FCT_BillingRecord" module to consolidate billing information for loading into the BRM database.

About Discounting Modules

Discounting modules run after rating modules. Pipeline discounting uses the following processes:

The module checks for the conditions that allow a discount; for example, using 100 minutes per month.
The module grants the discount; for example, reducing the charge by 10%.

You set up discounting by configuring the following discounting modules in a pipeline:

Use the "FCT_DiscountAnalysis" module to analyze EDRs before discounting.
Use the "FCT_Discount" module to calculate and apply discounts.

About Roaming Modules

Roaming modules rate roaming usage. You set up roaming rates by configuring the following modules in a pipeline. Use the "FCT_CarrierIcRating" module to supply the interconnect charge for the FCT_MainRating module.

About iScripts and iRules

Use iScripts and iRules to create custom pipeline functionality. For example, you can perform additional processing on data or add data to EDRs.

Use iScripts to perform the same operation on every EDR. Use iRules when you need to run an operation only under certain conditions.

How Pipeline Manager Uses BRM Data

Pipeline Manager needs to get data from the BRM database to rate each account. For example, Pipeline Manager gets the charge to use from the services and products/ charge offers owned by an account. Pipeline Manager also gets historical data; for example, if a customer changes a phone number, Pipeline Manager needs the old number to rate calls made using it.

Pipeline Manager also needs to get data that is not required for rating but is required by the BRM event objects that Rated Event (RE) Loader loads into the BRM database. For example, every event requires an item, so Pipeline Manager needs to get the correct item for the event. When the rated event is loaded, the correct item is already recorded in the event.

How Pipeline Manager Identifies Accounts

When Pipeline Manager rates usage events, there is no information in the original CDR that specifies which BRM account was responsible for the event. Pipeline Manager needs to know the account to rate the event and to apply discounts.

To find the account:

In the EDR, Pipeline Manager finds the phone number identified as the calling number.
In the data retrieved from BRM, this number is stored in the alias list in a service object. Once the service object is found, it has a pointer to the account object, from which Pipeline Manager identifies the account.

How Pipeline Manager Chooses a Charge

Pipeline Manager needs a charge for determining usage charges. There are three ways that Pipeline Manager can find out which charge to use:

Product/Charge offer priority. By default, Pipeline Manager uses the charge associated with the highest-priority product/charge offer. That is, it searches through all purchased products/charge offers, from highest priority to lowest priority, until it finds one that matches the event's rating criteria, such as the zone model and time model type. It then selects the charge associated with that charge offer. You assign priorities to products/charge offers.
Lowest charge. When configured for least cost rating, Pipeline Manager finds the product/charge offer that generates the lowest overall charge to the customer and then uses the charge associated with the product/charge offer. You configure a pipeline for least cost rating by using the IRL_LeastCostPerEDR and ISC_LeastCost modules. See "About Least Cost Rating".
ERA. If a service or an account is associated with an extended rating attribute (ERA), Pipeline Manager uses the charge you configure and prioritize for the ERA.

Note:

If a subscription service and member service both own a service-level ERA, the member service's ERA has priority and is used for selecting the charge.

How Pipeline Manager Assigns Delayed Events to Items

When Pipeline Manager outputs events to RE Loader, the events must include all mandatory event data. Most of that data comes from the incoming CDR; for example, the call origin and destination. Some of the data must come from BRM, including which bill item stores the balance impact of the event.

In BRM, every event object is associated with a bill item. The incoming CDR does not have any information about bill items, so Pipeline Manager gets that information from BRM.

In the EDR, Pipeline Manager finds the phone number identified as the calling number.
In the data retrieved from BRM, this number is stored in the alias list in a service object. Once the service object is found, Pipeline Manager uses the information in the item POID list to determine which bill item the event applies to.

BRM creates service usage items for the next accounting cycle on four occasions:

When the service is purchased by an account.
When billing is run.
When the Bill Now feature is used in Billing Care.
When a usage event occurs.

However, BRM does not create a usage item when Pipeline Manager processes an event. If no usage item exists, Pipeline Manager rejects the event. Therefore, BRM pre-creates usage items for Pipeline Manager to use.

BRM pre-creates items in the following cases:

When an account is created.
When you run billing.
When a CSR uses Bill Now.
At the end of the accounting cycle when you use delayed billing.

Note:

To maintain correct discount balances, and to minimize rejected EDRs, always use delayed billing when you use pipeline rating.

To choose the correct bill item, Pipeline Manager can do one of the following:

Assign the event to the current open bill item.
Assign the event to the next open bill item.
Reject the event because it belongs to an item that has already been included in a bill.

To decide which item to apply the bill to, Pipeline Manager takes into account the following dates:

The date when the call occurred (the EDR date).
The current system date.
The date when the current accounting cycle ends. This is called the next accounting cycle date.
The number of days after the current accounting cycle ends when delayed billing runs. This number is called the delayed billing offset.

Note:

You can set up an accounting cycle delay period to manage which items delayed events are assigned to. This is useful when your billing cycle spans multiple accounting cycles. See "About Accounting Cycle Delay Periods".

To assign the event to an item:

If the EDR date falls before the next accounting date, the event is assigned to the current item.
If the EDR date falls after the next accounting date, the event is assigned to the next item. This can happen because the event might occur after the close of the accounting cycle but before the delayed billing offset date.

Figure 17-4 shows how events are assigned:

Figure 17-4 Event Assignment

Description of "Figure 17-4 Event Assignment"

Note:

The customer billing date is not relevant when choosing which item to use for the event. There might be multiple accounting cycles in one billing cycle. New items are created for each accounting cycle.

If Pipeline Manager needs to assign an event to the current item, but billing for that item has already occurred, Pipeline Manager includes the event and assigns it to the current item. For example, if the event is rated on May 20 and loaded after the account cycle ends, it is still included in the current item as shown in Figure 17-5.

Figure 17-5 Current Event Assignment After Billing

Description of "Figure 17-5 Current Event Assignment After Billing"

About Accounting Cycle Delay Periods

In the batch pipeline, events that occur in one cycle can sometimes be rated and loaded into the BRM database after that cycle is completed. To assign delayed events to items of the billing cycle in which they occurred, you configure delayed billing. To assign delayed events to items of the accounting cycle in which they occurred, you configure an accounting cycle delay period.

When a billing cycle spans multiple accounting cycles, the items for those accounting cycles are not closed until billing is run. If you run a general ledger (G/L) report at the end of an accounting cycle for which billing has not yet been run, the status of the revenue in the G/L can change if additional events are rated and loaded for that cycle before the accounts are billed.

If you require that G/L data not change after the G/L report is run, you can configure an accounting cycle delay period after which events are no longer assigned to items of that accounting cycle, even if those items are not closed. You then run G/L reports after the accounting cycle delay period has ended. This ensures that the revenue reported in the G/L is accurately represented and that the state of the revenue (earned, unearned, billed, and unbilled) does not change after the G/L report is run.

Note:

To use an accounting cycle delay period, you must also configure delayed billing.

When you configure an accounting cycle delay period, BRM assigns delayed events to items based on when the accounting cycle delay period ends. BRM assigns events to items when RE Loader loads the events into the database:

When delayed events (events that occurred in the previous cycle) are loaded after the accounting day of month (DOM), but before the end of the accounting cycle delay period, those events are posted to the item for which the DOM has just passed as shown in Figure 17-6:

Figure 17-6 Delayed Events Arriving During Cycle Delay Period

Description of "Figure 17-6 Delayed Events Arriving During Cycle Delay Period"

When the billing cycle has ended and delayed events are loaded after the end of the accounting cycle delay period, but before delayed billing is run, those events are posted to the item for the next (current) accounting cycle, even though the previous cycle has not been billed and its items are still pending. This is shown in Figure 17-7:

Figure 17-7 Delayed Events Arriving After Cycle Delay Period

Description of "Figure 17-7 Delayed Events Arriving After Cycle Delay Period"

After the account is billed, items for the billed cycle are closed so delayed events are posted to the item for the following (the current) cycle.

Note:

If the accounting cycle delay period is longer than the delayed billing period, the accounting cycle delay period is ignored after billing is run. After billing is run, if any remaining events that occurred in the previous cycle are rated and loaded in the current cycle, they are assigned to the current cycle's item.

You specify the accounting cycle delay period by modifying a business parameter configuration (/config/business_params object). RE Loader checks the accounting cycle delay period in the /config/business_params object before loading events. See "Configuring an Accounting Cycle Delay Period".

Configuring an Accounting Cycle Delay Period

By default, an accounting cycle delay period is disabled. You can enable this feature by modifying a field in the billing instance of the /config/business_params object.

You modify the /config/business_params object by using the pin_bus_params utility.

To configure an accounting cycle delay period:

Use the following command to create an editable XML file from the billing instance of the /config/business_params object:
```
pin_bus_params -r BusParamsBilling bus_params_billing.xml
```
This command creates the XML file named bus_params_billing.xml.out in your working directory. The file contains the current billing configuration values in the /config/business_params object in the BRM database. If you don't want this file in your working directory, specify the path as part of the file name.
Open bus_params_billing.xml.out file and search for the following line:
```
<AcctCycleDelayPeriod>-1</AcctCycleDelayPeriod>
```
Change -1 to the number of days in the accounting cycle delay period. The number of days must be a positive value. (A value of -1 indicates that there is no accounting cycle delay period.)

For example, if the accounting cycle delay period is 3 days and the accounting cycle ends at midnight on March 31, the delay period ends at midnight on April 3.

Note:

BRM uses the XML in this file to overwrite the existing billing instance of the /config/business_params object. If you delete or modify any other parameters in the file, these changes affect the associated aspects of the BRM billing configuration.

Note:

Do not set the accounting cycle delay period to be longer than the delayed billing period.
Save and close the bus_params_billing.xml.out file and rename the file to bus_params_billing.xml.
Use the following command to load this change into the /config/business_params object:
```
pin_bus_params bus_params_billing.xml
```
You should execute this command from the BRM_home/sys/data/config directory, which includes support files used by the utility. BRM_home is the directory where you installed BRM components.
Read the object by using the testnap utility or Object Browser to verify that all fields are correct.
Stop and restart the Connection Manager (CM).

About G/L IDs

Pipeline Manager uses G/L IDs defined in the Pipeline Manager database. However, those G/L IDs must match the G/L IDs in the BRM database. You should define G/L IDs in the BRM database first and then in Pipeline Manager.

About Mapping Balance Elements between the Pipeline Manager Database and the BRM Database

Balance Element IDs must match between the Pipeline Manager database and the BRM database. In addition, you can configure how Pipeline Manager balance elements map to BRM balance elements. For example, Pipeline Manager can separate balance element amounts in a variety of ways, but you might want to combine balance element amounts when defining BRM balance impacts.

Figure 17-8 shows how the charges for a GPRS event can be mapped between the Pipeline Manager database and the BRM database:

Figure 17-8 GPRS Charge Mapping Between BRM and the Pipeline Manager

Description of "Figure 17-8 GPRS Charge Mapping Between BRM and the Pipeline Manager"

How Pipeline Manager Gets Historical Data

Because there is a gap of time between when a call occurs and when it is rated, information about the customer can change during that time. For example, a customer might change the phone number before a call is rated. Pipeline Manager needs to look up account data based on the old number.

To retrieve historical information, Pipeline Manager gets data from audited objects. By default, auditing in BRM is turned off for most objects. After you install the Account Synchronization DM, you must run the object_auditing.pl script to turn on auditing for the objects and fields that Pipeline Manager needs data about.

In addition, Pipeline Manager pricing configuration data includes validity dates that can be used to apply the correct rating to delayed events.

About Loading Pipeline-Rated Event Data

Pipeline Manager sends the results of rating to output files. BRM loads the data in these files into the BRM database.

You configure BRM Batch Controller to start a batch handler when rated event files are ready for loading.

You configure a batch handler to load the rated-event data into the BRM database. The batch handler runs the utilities that load the data.

BRM provides the following sample batch handlers that you can use to load pipeline-rated events:

SampleRelHandler: This batch handler starts the Rated Event (RE) Loader utility (pin_rel). The utility loads data for events that are rated in batches.
OODHandler: This batch handler starts the rerate-request loader utility (pin_load_rerate_jobs). The utility creates rerate jobs for events that were rated out of order.
SampleHandler: This batch handler starts the Universal Event (UE) Loader utility (uel). The utility loads batches of events into the BRM database for rating by the rating opcodes. UE Loader is also used by Pipeline Manager to load various types of data files that it generates during rating; for example, validity period data for products/charge offers, discounts/discount offers, and balance elements that start on first usage, roaming settlement data, and revenue assurance data.
ConfigurableValidityHandler: This batch handler starts the pin_rel and pin_load_rerate_jobs utilities, and the instance of uel that loads first-usage validity data, thereby eliminating the need to configure separate instances of the handlers for these utilities. For more information, see "About Using a Single Batch Handler to Run Multiple Loading Utilities".

About Using a Single Batch Handler to Run Multiple Loading Utilities

If you use Pipeline Manager to rate products/charge offers, discounts/discount offers, or granted balance elements that start on first usage, you configure the ConfigurableValidityHandler sample batch handler to run the utilities for RE Loader (pin_rel), UE Loader (uel), and out-of-order rerating (pin_load_rerate_jobs).

Note:

If you do not wish to use a single batch handler to run these utilities, you can configure the individual sample batch handlers provided for RE Loader, UE Loader, and out-of-order rerating.

ConfigurableValidityHandler runs pin_rel, uel, and pin_load_rerate_jobs instances sequentially, waiting for one process to complete before starting the next. In a single sequence, ConfigurableValidityHandler processes files that were produced for the same CDR file or for the same pipeline transaction (if the pipeline is configured to produce an output file per transaction instead of per CDR file).

When pipeline rating outputs a file of rated events, the ConfigurableValidityHandler batch handler performs the following tasks:

Runs pin_rel to load the results of pipeline rating into the BRM database.

For more information about RE Loader, see "Understanding Rated Event Loader".
Checks for first-usage validity files for products/charge offers and discounts/discount offers and, if one exists for the same CDR or transaction, runs uel to load the product/charge offer and discount/discount offer validity data.

For more information about using UE Loader to load validity data, see "About Updating Validity Period Information in the BRM Database".
Checks for first-usage files for balance elements and, if one exists for the same CDR or transaction, runs uel again to load the balance element validity data.
Checks for rerate-request files for events rated out of order and, if one or more exist for the same CDR or transaction, runs pin_load_rerate_jobs for each file.

ConfigurableValidityHandler handles errors in the following ways:

If pin_rel does not successfully load the pipeline batch-rated events, the failure is logged in the handler log file (configurable_validity_handler.log) and uel and pin_load_rerate_jobs are not run.
If uel or pin_load_rerate_jobs fails, the entire process is recorded as failed in the handler log file.

If all processes are successful, the configurable_validity_handler.log file is deleted. If one or more processes are not successful, the configurable_validity_handler.log file is not deleted.

Along with processing information and status, the log files include the name of the input file that was loaded. If pin_rel loads a rated-event file and there were no associated first-usage validity files or rerate-request files, this is noted in the log file.

About Pipeline Rating and BRM Billing

When Pipeline Manager receives an EDR for the next billing cycle for an account that hasn't yet been billed, the EDR is suspended (not rated). Only when the account's billing process is complete can the new EDRs be rated.

The number of accounts being billed affects the time it takes to complete the billing process. The longer the processing time, the greater the chance EDRs might need suspending or rerating. If you process many EDRs and need accounts to be billed quickly so that their new usage can be rated, you can set up Pipeline Manager to trigger billing. When Pipeline Manager triggers billing for an account, it is billed in a separate billing process.

Function Module Dependencies

Table 17-1 provides guidelines for how to configure the order of function modules in a pipeline. The modules are listed in a typical order, but your configuration might vary. Some modules require that other modules be run first, whereas some modules can be located anywhere in the pipeline.

For more information, see the reference documentation for the module.

Table 17-1 Functional Modules and Processing Dependencies

Function module	Processing dependencies
FCT_PreSuspense	Must be the first preprocessing module in a pipeline.
ISC_SetAndValidateBatchInfo	This is the first iScript that must be used so that the batch ID gets inserted before any further processing of the mediation batches.
FCT_DuplicateCheck	Should run early in a pipeline to discard duplicate EDRs.
FCT_CallAssembling	Should run early in a pipeline to assemble EDRs. Must run before FCT_Discard.
FCT_ServiceCodeMap	Some modules require an internal service code, so this module should run near the front of a pipeline.
ISC_CiberInputValidation	Because erroneous CIBER records can be discarded, this module must run before the FCT_Discard module.
FCT_Discard	Because you can discard or split EDRs based on service codes, this module should run after the FCT_ServiceCodeMap module. Should be early in the function pool, but must be run after FCT_CallAssembling.
iRuleValidation	Run this iRule before ISC_TapSplitting.
ISC_TapSplitting	Must run after the following modules: FCT_DuplicateCheck FCT_Discard
FCT_AccountRouter	For general use, this module must run after the FCT_ServiceCodeMap module and before the rating modules. For use with standard recycling or Suspense Manager using multiple database schemas, this module must run before OUT_GenericStream in a pre-recycling pipeline. This module sends output to a separate pipeline for each BRM database schema.
FCT_EnhancedSplitting	Because you can split EDRs based on service codes, this module should run after the FCT_ServiceCodeMap and FCT_UsageClassMap modules.
FCT_CliMapping	Must run before the rating modules.
FCT_UoM_Map	Must run after the FCT_ServiceCodeMap module and before the rating modules.
FCT_UsageClassMap	Must run before the zoning and rating modules.
FCT_NumberPortability	Must run before the zoning and rating modules.
ISC_MapNetworkOperatorInfo	Must run after the FCT_NumberPortability module and the ISC_PopulateOpcodeAndUtilBlock_Diameter iScript.
FCT_NOSP	Must run before segment rating is performed.
FCT_Account	Must run before the zoning and rating modules.
ISC_ProfileAnalyzer	Must run after FCT_Account and before any rating modules.
ISC_ProfileLabel	Must run after FCT_Account and before any rating modules.
IRL_UsageType	Must run after FCT_Account and before FCT_USC_Map.
FCT_CiberOcc	Must run after the FCT_DuplicateCheck module and before the FCT_CarrierIcRating module.
FCT_ItemAssign	Must run after the FCT_Account, rating, and discounting modules and before the FCT_BillingRecord module.
FCT_CustomerRating	Must run after FCT_Account.
FCT_Filter_Set	Must run after FCT_Account.
IRL_PromotionalSavingPerEDR	Must run before IRL_LeastCost and FCT_CustomerRating.
IRL_LeastCostPerEDR	Must run before FCT_CustomerRating and after "FCT_Filter_Set".
FCT_CustomerRating	Must run after FCT_Account.
ISC_LeastCost	Must run after FCT_CustomerRating.
FCT_CiberOcc	Must run after the FCT_DuplicateCheck module and before the FCT_CarrierIcRating module.
FCT_CarrierIcRating	Must run after FCT_Account.
FCT_DroppedCall	Must run after FCT_Account.
FCT_APN_Map	Can run before or after the zoning modules (FCT_Zone and FCT_PreRating).
FCT_PreRating	Must run before the FCT_MainRating module.
FCT_SegZoneNoCust	Must run after the prerating module
FCT_MainZoning	Must run after the FCT_SegZoneNoCust module.
FCT_Zone	Must run after FCT_Account.
FCT_USC_Map	Must run after the following: FCT_UsageClassMap ISC_UsageType FCT_PreRating
FCT_TriggerBill	Must run before the FCT_MainRating module.
FCT_MainRating	Must run after at least one of the following modules: FCT_GlobalRating FCT_CustomerRating FCT_CarrierIcRating
FCT_RSC_Map	Must run after the FCT_MainRating module to adjust the rate.
FCT_Dayrate	Must run after the FCT_MainRating module to adjust the rate.
FCT_RateAdjust	Must run after the FCT_MainRating module to adjust the rate.
FCT_Rounding	Must run after the FCT_RateAdjust module if you want rating results to be rounded and after FCT_Discount module if you want discount results to be rounded. FCT_Rounding must come after each module for which rounding should occur. For batch rating, it must come before the FCT_ApplyBalance module.
FCT_ExchangeRate	Must run after the FCT_MainRating module.
ISC_FirstProductRealtime	Must run this iScript in the real-time rerating pipeline before the FCT_DiscountAnalysis module.
FCT_DiscountAnalysis	For pipeline rating, must run after the FCT_Account module and before the FCT_Discount module. For real-time rating, must run before the FCT_Discount module.
FCT_Discount	Must run after the FCT_MainRating module. For batch rating, this module should be in the same function pool as the FCT_ApplyBalance module and run before that module.
FCT_FirstUsageNotify	Must run this module before the FCT_ApplyBalance and FCT_Reject modules.
FCT_ApplyBalance	Must run after the FCT_Rounding module. This module should be in the same function pool as the FCT_Discount module and run after that module.
ISC_TaxCalc	Must Run this module before the FCT_BillingRecord module, but after the FCT_MainRating module.
FCT_BillingRecord	Must run after the FCT_MainRating and FCT_Discount modules.
FCT_EventOrder	Must run after the FCT_MainRating and FCT_Discount modules and before the FCT_Reject module.
ISC_CiberOutputMapping	Must run after the FCT_MainRating module and ISC_PostRating iScript.
IRL_EventTypeSplitting	Must run after FCT_ServiceCodeMap and before the FCT_Reject module. This is typically the last module before the FCT_Reject module.
FCT_Reject	Runs after the rating and discount modules.
ISC_SetOutputStream	Must run after FCT_Reject.
ISC_PostRating	Must run: After rating modules FCT_CustomerRating, FCT_PreRating, and FCT_MainRating or After the FCT_ExchangeRate module
ISC_SetEDRStatus	Must run before FCT_AggreGate.
ISC_SetRevenueFigures	Must run after rating and discounting and before FCT_AggreGate.
ISC_SetRevenueStream	Must run before FCT_AggreGate and after post rating (after the EDRs are rated).
ISC_SetEDRStatus	Must be run before the FCT_AggreGate scenario that collects audit data grouped on the EDRStatus field.
FCT_AggreGate	Runs after rating modules. This module usually runs in its own pipeline.
FCT_CancelTimer	Depends on the FCT_Timer in the Dispatcher pipeline for the TimerID and the timeout flag values.
FCT_Recycle	For pipeline-only recycling, must be the last module in the pipeline.
FCT_Suspense	For standard recycling and Suspense Manager, must be the last module in a pipeline.

The following modules do not have any placement dependencies and can be run anywhere in a pipeline or in a separate pipeline, depending on the data that is being processed:

Figure 17-9 shows the order of the most common function modules:

Figure 17-9 Order of Common Function Modules

Description of "Figure 17-9 Order of Common Function Modules"

Data Module Dependencies

This section provides guidelines for how to configure the order of data modules in the registry file. Some modules require that other modules be run first, whereas some modules can be located anywhere in the pipeline.

"DAT_PortalConfig". Due to the dependency of other data modules on DAT_PortalConfig, the DAT_PortalConfig registry entries must appear before all other data module entries in the registry file.