Skip Headers
Oracle® Communications Billing and Revenue Management Configuring Pipeline Rating and Discounting
Release 7.5

E16710-08
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

1 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.

Before reading this document, you should be familiar with BRM concepts and architecture. See the following documents:

How Events Are Rated by Using Pipeline Manager

Pipeline Manager rates usage events as follows:

  1. Call detail record (CDR) files are collected from network switches and processed by mediation software. The mediation software converts data into the BRM CDR format so it can be read by a pipeline input module. See "About the BRM 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.

  2. The mediation software places the CDR file in a predefined directory.

  3. 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.

  4. 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.

  5. The output module writes data to an output file.

  6. Rated Event (RE) Loader reads the output file, loads the events into the BRM database, and updates the customer's account balance.

Figure 1-1 shows how usage events are rated:

Figure 1-1 Usage Events Rating

Description of Figure 1-1 follows
Description of "Figure 1-1 Usage Events Rating"

When you configure Pipeline Manager, you do the following:

  • Use Pricing Center to configure rating, pricing, and zoning data.

  • 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:

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 BRM CDR Format

The BRM CDR format is the standard CDR file format used by Pipeline Manager for processing CDRs. For example, the BRM 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 BRM CDR format can also be used as the input format for rating pipelines. Additionally, pipelines can be configured to translate other formats into the BRM CDR format for rating.

For complete details about the BRM 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 rate plan 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 rate plan 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:

  1. The EDR Factory creates an EDR container according to the information in the container description file.

  2. The input module writes data to relevant fields in the container. For more information, see "Configuring EDR Input Processing".

  3. The function modules process data in or add data to particular fields. For example, the FCT_BillingRecord function module processes balance impact-related data.

  4. 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. See "Modifying and Loading the EDR Container Description" in BRM Setting Up Pricing and Rating.

Important:

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. For information, see "Modifying and Loading the EDR Container Description" in BRM Setting Up Pricing and Rating.

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 1-2 shows the BRM EDR container organization:

Figure 1-2 BRM EDR Container Organization

Description of Figure 1-2 follows
Description of "Figure 1-2 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 resource, 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 resources, each resource 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.

For more information, see "About Pipeline Manager Transactions" in BRM System Administrator's Guide.

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. You can view all the existing BRM-defined and custom alias names in the alias mapping table in Pricing Center.

Viewing and Creating Alias Mapping for an EDR Field

Use Pipeline Setup Toolbox -EDR- EDR Container Description - Alias Mapping in Pricing Center to view a list of existing alias mappings and to add custom alias mappings.

See Pricing Center Help.

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:

About Preprocessing Modules

Use the preprocessing modules to handle the following tasks:

You set up EDR preprocessing by configuring modules in a pipeline. In some cases, you use Pricing Center to configure how a module works; for example, to set up discard rules. 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.

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 setting up mapping rules in Pricing Center and configuring mapping modules in a pipeline. For more information about service mapping, see "Setting up Pipeline Price List Data" in BRM Setting Up Pricing and Rating.

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.

  • Use the "FCT_SegRateNoCust" module to find the segment using the source network information instead of using the customer information.

You set up zoning by creating zone models in Pricing Center and configuring zoning modules in a pipeline. For more information about zoning, see "Setting up Zones for Batch Pipeline Rating" in BRM Setting Up Pricing and Rating.

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 rate plan to all EDRs.

  • Use the "FCT_CustomerRating" module to provide customer data for other rating modules.

  • Use the "FCT_SegRateNoCust" module to perform business analysis.

  • 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.

You set up rating by configuring rate plans in Pricing Center and configuring rating modules in a pipeline. For information about each module, and how pipeline rating works, see "Configuring Pipeline Rating".

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 discount models in Pricing Center and configuring the following discounting modules in a pipeline:

About Roaming Modules

Roaming modules rate roaming usage. You set up roaming rates by using Pricing Center and configuring the following modules in a pipeline:

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.

Fore more information, see "Creating iScripts and iRules" in BRM Developer's Guide.

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 rate plan to use from the services and products 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.

Pipeline Manager also supplies additional data needed for rating or for creating a valid event. For example, Pipeline Manager supplies the G/L ID for the event (although the G/L IDs must match in the pipeline pricing data and real-time rating pricing data).

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:

  1. In the EDR, Pipeline Manager finds the phone number identified as the calling number.

  2. 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.

For information about configuring how to identify accounts in Pipeline Manager, see "Specifying Which Data is Used for Identifying Accounts" in BRM Setting Up Pricing and Rating.

How Pipeline Manager Chooses a Rate Plan

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

  • Product priority. By default, Pipeline Manager uses the rate plan associated with the highest-priority product. That is, it searches through all purchased products, 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 rate plan associated with that product. You assign priorities to products in your pipeline rate plan. See "About Creating a Price List" in BRM Setting Up Pricing and Rating.

  • Lowest charge. When configured for least cost rating, Pipeline Manager finds the product that generates the lowest overall charge to the customer and then uses the rate plan associated with the product. 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 rate plan you configure and prioritize for the ERA in Customer Center. See "About Extended Rating Attributes for Telco Services" in BRM Telco Integration.

    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 rate plan. See "Managing Customers' Subscription-Level Services" in BRM Managing Customers.

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.

  1. In the EDR, Pipeline Manager finds the phone number identified as the calling number.

  2. 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 Customer Center.

  • 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.

    Important:

    To maintain correct discount balances, and to minimize rejected EDRs, always use delayed billing when you use pipeline rating. See "Setting up Delayed Billing" in BRM Configuring and Running Billing.

For information about setting up precreated items, see "Setting Up Service-Level Bill Items" in BRM Installation Guide.

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. (For more information, see "Setting up Delayed Billing" in BRM Configuring and Running Billing.)

    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 1-3 shows how events are assigned:

Figure 1-3 Event Assignment

Description of Figure 1-3 follows
Description of "Figure 1-3 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 1-4.

Figure 1-4 Current Event Assignment After Billing

Description of Figure 1-4 follows
Description of "Figure 1-4 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.

Important:

To use an accounting cycle delay period, you must also configure delayed billing. See "Setting up Delayed Billing" in BRM Configuring and Running 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 1-5:

Figure 1-5 Delayed Events Arriving During Cycle Delay Period

Description of Figure 1-5 follows
Description of "Figure 1-5 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 1-6:

Figure 1-6 Delayed Events Arriving After Cycle Delay Period

Description of Figure 1-6 follows
Description of "Figure 1-6 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. For information on this utility, see "pin_bus_params" in BRM Developer's Guide.

To configure an accounting cycle delay period:

  1. 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.

  2. Open bus_params_billing.xml.out file and search for the following line:

    <AcctCycleDelayPeriod>-1</AcctCycleDelayPeriod>
    
  3. 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.

    Caution:

    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.

    Important:

    Do not set the accounting cycle delay period to be longer than the delayed billing period.
  4. Save and close the bus_params_billing.xml.out file and rename the file to bus_params_billing.xml.

  5. 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. To execute it from a different directory, see "pin_bus_params" in BRM Developer's Guide.

  6. Read the object by using the testnap utility or Object Browser to verify that all fields are correct:

  7. Stop and restart the Connection Manager (CM). See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.

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 Resources between the Pipeline Manager Database and the BRM Database

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

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

Figure 1-7 GPRS Charge Mapping Between BRM and the Pipeline Manager

Description of Figure 1-7 follows
Description of "Figure 1-7 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. For more information, see "Turning on Object Auditing" in BRM Installation Guide.

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, discounts, and resources 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, discounts, or granted resources 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).

For information about validity periods that start on first usage, see "About Effective Periods That Start on First Usage" and "About Balance Impacts That Become Valid on First Usage" in BRM Setting Up Pricing and Rating.

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:

  1. 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".

  2. Checks for first-usage validity files for products and discounts and, if one exists for the same CDR or transaction, runs uel to load the product and discount validity data.

    For more information about using UE Loader to load validity data, see "About Updating Validity Period Information in the BRM Database".

  3. Checks for first-usage files for resources and, if one exists for the same CDR or transaction, runs uel again to load the resource validity data.

  4. 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.

    For more information about rerating out-of-order events, see "About Automatic Rerating of Out-Of-Order Events" in BRM Setting Up Pricing and Rating.

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.

For more information, see "Setting up Pipeline-Triggered Billing" in BRM Configuring and Running Billing.

Function Module Dependencies

Table 1-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 1-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_SegRateNoCust

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). See "Setting up APN Mapping" in BRM Setting Up Pricing and Rating.

FCT_PreRating

Must run before the FCT_MainRating module.

FCT_SegZoneNoCust

Must run before the FCT_MainZoning 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_SegRateNoCust

  • 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.

FCT_FirstUsageNotify

Must run this module before the FCT_ApplyBalance and FCT_Reject modules.

FCT_ApplyBalance

Must run after the FCT_Rounding 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 1-8 shows the order of the most common function modules:

Figure 1-8 Order of Common Function Modules

Description of Figure 1-8 follows
Description of "Figure 1-8 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.