4 About Processing Visiting Subscribers' Roaming Usage

This chapter describes the roaming outcollect process in Oracle Communications Billing and Revenue Management (BRM) for rating visiting subscribers' roaming usage.

Important:

  • The following sections describe the outcollect process for processing TAP files only.

  • To process TAP files, TAP Roaming Manager requires Suspense Manager, Rated Event (RE) Loader, and InterConnect Manager to rate roaming usage. Suspense Manager, RE Loader, and InterConnect Manager are not part of TAP Roaming Manager and require separate licenses. You must install these supporting managers to rate roaming events. See "About Suspense Manager" and "Understanding Rated Event Loader" in BRM Configuring Pipeline Rating and Discounting for more information.

Before reading this document, you should be familiar with the following:

Understanding Roaming Outcollect Architecture and Process Flow

You use roaming outcollect processing to process call detail records (CDRs) generated by visiting subscribers on your network. The outcollect process architecture primarily consists of the splitter, outcollect rating, and settlement pipelines. These pipelines perform the following tasks:

  • The splitter pipeline separates home subscribers' CDRs from visiting subscribers' roaming CDRs.

  • The outcollect rating pipeline rates the visiting subscribers' roaming CDRs based on InterCarrier Tariff rates and generates outcollect TAP files for each roaming partner.

  • The settlement pipeline creates settlement events by associating visiting subscribers' roaming CDRs with corresponding roaming partner accounts in the BRM database. These settlement events are loaded into the BRM database and impact your roaming partners' account balance.

Figure 4-1 depicts a high-level overview of the roaming outcollect process architecture:

Figure 4-1 Roaming Outcollect Process Architecture

Description of Figure 4-1 follows
Description of ''Figure 4-1 Roaming Outcollect Process Architecture''

As Figure 4-1 illustrates, incoming CDRs are handled during the outcollect process as follows:

  1. The splitter pipeline converts the CDRs into event data record (EDR) format and separates the EDRs into home subscribers' EDRs and visiting subscribers' roaming EDRs.

    • Home subscribers' EDRs are sent to the normal rating pipeline to be rated and loaded into the BRM database by RE Loader. If the rating pipeline fails to rate the EDR, the EDR is suspended and recycled by using Suspense Manager.

    • Visiting subscribers' roaming EDRs are sent to the outcollect rating pipeline to be rated.

    See "How Home CDRs Are Separated from Visiting Subscribers' CDRs" for more information.

  2. The outcollect rating pipeline rates the visiting subscribers' roaming EDRs and generates outcollect TAP files, for each roaming partner network operator, that you send to your roaming partners for verification and billing purposes. A copy of the outcollect TAP file is forwarded to the settlement pipeline for further processing.

    If the outcollect rating pipeline fails to rate the roaming EDR, the EDR is suspended and recycled by using Suspense Manager.

    See "How Visiting Subscribers' Roaming CDRs Are Rated" for more information.

  3. The settlement pipeline processes the outcollect TAP file and creates settlement events by associating the events with roaming partner accounts in the BRM database. Settlement events are loaded into the BRM database by RE Loader.

    If the settlement pipeline fails to create settlement events, the entire TAP file is suspended and loaded into the BRM database. The suspended TAP file can be corrected and recycled back to the settlement pipeline by using Suspense Manager.

    See "How Settlement Events for Incollect Roaming Charges Are Created" for more information.

For detailed information on configuring outcollect processing, see "Setting Up Pipeline Manager for Roaming Outcollect Processing".

How Home CDRs Are Separated from Visiting Subscribers' CDRs

The splitter pipeline processes CDRs as follows:

  • Incoming CDRs are converted to EDR format.

    The INP_GenericStream module provides the input interface to the splitter pipeline using BRM standard input grammar files. The input grammar converts CDRs into the internal EDR format that can be used by all BRM modules. If there are any errors, INP_GenericStream adds the error to the EDR container and sends the EDR to the reject stream.

    See "INP_GenericStream" in BRM Configuring Pipeline Rating and Discounting for more information.

  • EDRs are separated into home and roaming EDRs.

    The FCT_EnhancedSplitting module separates the EDRs into home subscribers' EDRs and visiting subscribers' roaming EDRs so that they can be sent to the appropriate rating pipeline for processing.

    Home subscribers' EDRs are sent to the normal rating pipeline. Visiting subscribers' roaming EDRs are sent to the outcollect rating pipeline.

    You use Pricing Center to define the splitting rules: for example, you can define a rule using the source network EDR field to send home and roaming EDRs to different output streams.

    See "FCT_EnhancedSplitting" in BRM Configuring Pipeline Rating and Discounting for more information.

  • EDRs are written to output files.

    The OUT_GenericStream module uses standard BRM SOL42 output grammar to write home and roaming EDRs to separate output files.

    As soon as the splitter pipeline generates the output files with the roaming EDRs, the outcollect rating pipeline retrieves the files and rates the roaming EDRs. See "How Visiting Subscribers' Roaming CDRs Are Rated" for more information.

    Note:

    • The splitter pipeline is optional. If your mediation system separates home CDRs from roaming CDRs before they are sent to the BRM billing system, you do not need to use the splitter pipeline.

    • By default, the splitter pipeline does not validate incoming CDRs. You can choose to implement validation by writing your own custom iScripts and using Suspense Manager to handle any CDRs that are suspended due to validation failures.

For information about configuring the splitter pipeline, see "Configuring the Splitter Pipeline".

Transmitting CDRs to the Splitter Pipeline

External CDRs must be placed in the input directory of the splitter pipeline for the pipeline to process them. If your mediation system does not automatically place the CDRs in this directory, you can configure a Batch Controller and write a custom Batch Handler to move the CDRs to the splitter pipeline input directory.

For more information about Batch Controllers and Batch Handlers, see "Controlling Batch Operations" in BRM System Administrator's Guide for more information.

How Visiting Subscribers' Roaming CDRs Are Rated

The outcollect rating pipeline processes the roaming EDRs as follows:

  • The contents of the splitter pipeline output file are mapped to the EDR container.

    The INP_GenericStream module uses BRM standard input grammar to parse the file and convert its contents into EDRs for rating.

  • A plan and product are selected to rate the roaming EDR.

    Based on the roaming agreement you have with your roaming partner, you set up intercarrier tariff plans and intercarrier products in Pricing Center. These plans and products are stored in the following tables:

    • IFW_NETWORKOPER

    • IFW_NETWORKMODEL

    • IFW_ICPRODUCT

    • IFW_ICPRODUCT_GRP

    • IFW_ICPRODUCT_RATE

    • IFW_ICPRODUCT_CNF

    To find the correct price basis for rating the roaming event, the FCT_CarrierIcRating module searches these tables to determine the rate plan that applies to the roaming event. It then adds the rate plan and other information such as the network operator, zones for the A and B numbers, and so forth to the EDR container. See "FCT_CarrierIcRating" in BRM Configuring Pipeline Rating and Discounting.

    For information on setting up intercarrier tariff plans and intercarrier products, see "Defining Roaming Partner Accounts in the BRM Database".

  • The impact category is selected.

    The FCT_PreRating module reads the EDR container to determine the phone number that originated the call, the destination phone number, and the start and end times of the call. Using this and other information in the EDR, this module determines the impact category and adds it to the EDR container along with supporting information on the zone model, service codes, and so forth.

  • The EDR is rated and the result is rounded.

    The FCT_MainRating module evaluates the contents of the EDR and retrieves the appropriate pricing information from the pipeline database. It then calculates the charge amount for the event and adds information on the currency type and other rating characteristics. FCT_MainRating passes the EDR to the FCT_Rounding module, which rounds the charge amount.

  • The charge for the event is converted from the local currency to Special Drawing Right (SDR) currency.

    The FCT_ExchangeRate module converts the amount in the charge packet to TAP currency (SDR).

  • Basic service and supplementary service packets are added to the EDR container for GSM services.

    The ISC_MiscOutCollect module adds BASIC_SERVICE and SUPPLEMENTARY_SERVICE blocks to the EDR container for GSM services. This is done to ensure that the TAP file generated by the pipeline contains all the required information.

If the outcollect rating pipeline is unable to rate the EDR, the EDR is suspended. See "Processing EDRs Suspended by the Outcollect Rating Pipeline" for more information.

After the EDRs are rated, the output modules generate outcollect TAP files for each roaming partner. These files contain the rated EDRs (in TAP format) for that partner. Your roaming partner uses the outcollect TAP files to verify their subscribers' roaming usage against the bill you send them and to perform their own rating on the events to bill their subscribers.

The following steps are performed to create and route outcollect TAP files to roaming partner network operator output streams:

  1. A sequence number is generated for the outcollect TAP file.

    Each outcollect TAP file is assigned a sequence number. Your roaming partner uses the sequence number to ensure that the TAP file you have sent them is not a duplicate and that there are no missing TAP files.

    The Sequence Generator is an instance of the Sequencer module that generates sequence numbers.

    Using Pricing Center, you define a Sequence Generator for each roaming partner. You define each sequence by specifying a unique sequence key that identifies the roaming partner. Depending upon the roaming partner receiving the TAP file, the Sequence Generator generates the sequence number based on the sequence key. For more information about the Sequencer, see "About Sequence Checking" in BRM System Administrator's Guide.

    A Sequence Generator can only be associated with one output stream. Because outcollect processing creates separate output streams for each roaming partner, a single Sequencer cannot be shared by multiple output streams. You must configure a Sequencer for each roaming partner output stream. For information on configuring sequence generation for your roaming partners, see "Configuring the Outcollect Rating Pipeline Input Processing".

  2. The EDRs are written to the corresponding roaming partner output stream.

    The FCT_EnhancedSplitting module routes each rated EDR to the corresponding roaming partner output stream. You use Pricing Center to define the splitting rules; for example, you can define a rule to route EDRs to different output streams based on the source network EDR field. The output module at each network operator output stream uses TAP output grammar to write the EDRs to output files. If FCT_EnhancedSplitting module is unable to route the EDR to an output stream, the EDR is routed to the suspense output stream.

When the outcollect TAP files are ready, the pipeline notifies the Event Handler by sending it the EVT_OUTPUT_FILE_READY event. Upon receiving this event notification, the Event Handler starts the move_outcollectTap.pl script, which copies the TAP files into the common directory (where all roaming partner network operator TAP files are stored until settlement events have been created) and moves the original outcollect TAP files to the settlement pipeline input directory for creating settlement events. See "About Settling Roaming Charges" for more information.

Note:

Settlement events are created to record the roaming charges and used to bill your roaming partners. DO NOT send the outcollect TAP files to your roaming partner network operators until settlement events and TAP Header information file have been successfully created by the settlement pipeline. Otherwise, billing errors can occur.

Note:

You must edit the move_outcollectTap.pl script to specify the common directory. By default, move_outcollectTap.pl copies the outcollect TAP files to the Pipeline_home/data/outcollect/tapout/common directory and moves the original outcollect TAP files to the Pipeline_home/data/outcollect/settlement/in directory. See "Configuring the Outcollect Rating Pipeline Input Processing" for more information.

For more information on configuring the outcollect rating pipeline, see "Configuring the Outcollect Rating Pipeline".

Processing EDRs Suspended by the Outcollect Rating Pipeline

If the outcollect rating pipeline is unable to rate an EDR, it sets the error in the EDR and suspends it. The FCT_Reject module evaluates the error and routes the EDR to the suspense output stream as specified by the RejectStream pipeline registry entry.

Using Suspended Event (SE) Loader, you load the suspended EDRs into the BRM database. Using Suspense Management Center, you can query the suspended events and make the necessary corrections. After the corrections are made, you can recycle the events for processing.

When Pipeline Manager receives the recycle request, the INP_Recycle module retrieves the suspended records from the BRM database and routes the events to the pre-recycle pipeline. The pre-recycle pipeline converts the suspended events back to EDR format and sends the EDRs back to the outcollect rating pipeline for rating.

For detailed information about how EDRs are suspended and recycled, see "About Suspense Manager" in BRM Configuring Pipeline Rating and Discounting.

Transmitting Roaming EDRs to the Outcollect Rating Pipeline

In the default roaming registry, the outcollect rating pipeline's input stream is the same as the splitter pipeline's output stream. As soon as the splitter pipeline generates an output file, the outcollect rating pipeline processes the file.

You can choose to change the default behavior. For example, you can do any of the following:

  • Transfer output files from the splitter pipeline to the outcollect rating pipeline at release intervals. For example, you might want to send roaming EDRs for rating twice a day.

    To transfer roaming EDRs from the splitter pipeline to the outcollect rating pipeline at release intervals, you can do the following:

    • Set up the outcollect rating pipeline's input stream to be different from the splitter pipeline's output stream.

    • Configure a Batch Controller and a Batch Handler to move the roaming EDRs from the splitter pipeline's output stream to the input stream of the outcollect rating pipeline at specific time intervals.

    • Set the UnitsPerTranscation registry entry to a high number. The UnitsPerTransaction entry determines the number of input files received by the pipeline and consequently the number of output files generated.

  • Configure the outcollect rating pipeline to process the output files from the splitter pipeline only after a certain number of files have accumulated.

    To configure the outcollect rating pipeline to start processing after a certain number of input files has accumulated, you use the UnitsPerTransaction registry entry to specify the number of input files. For instance, when UnitsPerTransaction is set to 1, the pipeline starts processing as soon as it receives one input file. However, if UnitsPerTransaction is set to 10, the pipeline waits until ten input files are received before it starts to process them. For more information about pipeline transactions, see "About Pipeline Manager Transactions" in BRM System Administrator's Guide.

About Generation of Notification Files when there Is No Roaming Activity

The outcollect rating pipeline generates notification files when there is no roaming activity by a roaming partner's subscribers. If the input file of the outcollect rating pipeline does not contain any roaming EDRs for a network operator configured in this pipeline, a notification file is generated.

The notification file informs your roaming partner that none of its subscribers have been roaming on your network. The notification file is generated based on the information in the EDR header and trailer records and does not contain any call detail records.

About Sending Outcollect TAP Files to Your Roaming Partner

Note:

You send outcollect TAP files to your roaming partners only after settlement events and TAP Header information file have been successfully created by the settlement pipeline.

When the settlement pipeline finishes processing the outcollect TAP file, it notifies the Event Handler by sending it the EVT_OUTPUT_FILE_READY event. Upon receiving this event notification, the Event Handler starts the move_TapSent.pl script. This script identifies the corresponding outcollect TAP file previously stored in the common directory by the outcollect rating pipeline and moves the file to another pre-defined directory for sending the TAP file to your roaming partner or clearing house.

Note:

You must edit the move_TapSent.pl script to specify the common directory used for storing the outcollect TAP files and the directory used for sending the TAP files to your roaming partners or clearing house. By default, move_TapSent.pl uses the Pipeline_home/data/outcollect/tapout/common directory as the common directory and moves the TAP files to the Pipeline_home/data/outcollect/tapout/sent directory. See "Configuring the Outcollect Settlement Pipeline Input Processing".

About Processing Rejected Outcollect TAP Files and Records

When you send outcollect TAP files to a roaming partner, the roaming partner validates the files to ensure there are no errors. If the validation fails, the partner generates a RAP file that includes the failed outcollect TAP file and records and sends it to you for corrections.

RAP file processing involves:

  • Correcting and reprocessing the erroneous TAP files and records and generating new TAP files to send to your roaming partner.

  • Backing out the balance impacts of settlement events associated with the erroneous TAP files and records that were previously recorded in the BRM database.

RAP files are handled by the RAP processing pipeline as follows:

  • The RAP file is parsed by the input module and a RAP Acknowledgment file is generated that you send to your roaming partner. The file includes information about the network operator who sent the RAP file, network operator receiving the file, RAP file sequence number, Acknowledgment file creation timestamp, and Acknowledgment file available timestamp.

  • For a fatal error RAP file, the entire file is suspended and sent to the TAP correction pipeline for corrections. See "Error Correction for TAP Files with Fatal Errors" for more information.

  • For a severe error RAP file, the records are suspended and sent to the outcollect rating pipeline for processing. See "Error Correction for TAP Files with Severe Errors" for more information.

  • For a missing error RAP file, a set of TAP notification files is generated for each missing sequence number.

  • To back out the balance impacts of the outcollect TAP file or records, the pipeline creates an ASCII file that specifies the extraction criteria for extracting settlement events associated with the TAP file or records. The pin_event_extract utility uses this file to extract the settlement events from the BRM database for backout-only rerating. See "Backing Out the Balance Impacts for the Rejected TAP Files and Records" for more information.

For information on configuring the RAP processing pipeline, see "Configuring the RAP Processing Pipeline".

Figure 4-2 depicts a high-level overview of the RAP processing architecture:

Figure 4-2 RAP Processing Architecture

Description of Figure 4-2 follows
Description of ''Figure 4-2 RAP Processing Architecture''

Error Correction for TAP Files with Fatal Errors

TAP files with fatal errors are processed by RAP processing pipeline as follows:

  • The input module converts the contents of the TAP file back to EDR format and maps the contents to staging fields in the EDR container by using RAP input grammar.

  • The ISC_RAP_0105_InMap module maps the data in the staging fields to business fields in the EDR container. It creates a header and a trailer EDR that contain information about the RAP file and a single detail EDR that contains information about the rejected outcollect TAP file.

  • The ISC_DupRAPRecords module sends a copy of the detail EDR to an output stream. This output stream uses Event Extraction output grammar to write the EDRs to a file that is used by the pin_event_extract utility to extract settlement events from the BRM database for backout-only rerating. See "Backing Out the Balance Impacts for the Rejected TAP Files and Records".

  • The ISC_OverrideSuspenseParams module overrides the suspense parameters to recycle the suspended EDRs to the TAP correction pipeline.

The detail EDR is then routed to the suspense batch output stream. The suspense batch output stream writes the EDRs to a batch file. This batch file contains the TAP file name, location of the file, RAP error code, and the records in the TAP file. You load this file into the BRM database by using Suspended Batch (SB) Loader.

Using Suspense Management Center, you can query the suspended batch file to analyze the errors and resubmit the batch for processing. When Pipeline Manager receives the resubmit request, DAT_ResubmitBatch routes the batch file to the TAP correction pipeline.

In the TAP correction pipeline, the input mapping file maps the batch file into the EDR container. Using your own custom iScript, you implement the logic to make the necessary corrections by modifying and updating the EDR contents.

After the corrections have been made, the output module uses TAP output grammar to write the EDR to an output file, which includes the original outcollect TAP file sequence number and the original RAP file sequence number.

The TAP correction pipeline then notifies the Event Handler by sending it the EVT_OUTPUT_FILE_READY event. Upon receiving this event notification, the Event Handler launches the move_outcollectTap.pl script to copy the TAP file into the common directory (where all network operator outcollect TAP files are stored until settlement events have been created) and to move the TAP file to the settlement pipeline input directory for creating settlement events. See "About Settling Roaming Charges".

For information on configuring the TAP correction pipeline, see "Configuring the TAP Correction Pipeline".

Error Correction for TAP Files with Severe Errors

TAP files with severe errors are processed by RAP processing pipeline as follows:

  • The input module converts the call event detail records in the TAP file back to EDR format and maps the call event detail fields to staging fields in the EDR container by using RAP input grammar.

  • The ISC_RAP_0105_InMap module maps the data in the staging fields to business fields in the EDR container. It uses the lookup information in the TAP Header Information file, and information in the RAP file to create header and trailer EDRs. For each call event detail record, it creates an instance of the detail EDR with the call event details.

  • The ISC_DupRAPRecords module duplicates and sends a copy of the detail EDRs to the event extraction output stream. This output stream uses Event Extraction output grammar to write the EDRs to a file that is used by the pin_event_extract utility to extract settlement events from the BRM database for backout-only rerating. See "Backing Out the Balance Impacts for the Rejected TAP Files and Records" for more information.

  • The ISC_OverrideSuspenseParams module overrides the suspense parameters to recycle the suspended EDRs to the outcollect rating pipeline.

The detail EDRs are routed to the suspense output stream. The suspense output stream writes the EDRs to a suspense file. You load this file into the BRM database by using SE Loader.

Using Suspense Management Center, you can query the suspended EDRs and make the necessary corrections. After the corrections are made, you can recycle the EDRs for processing. When Pipeline Manager receives the recycle request, the DAT_Recycle module retrieves the suspended events from the BRM database and routes the events to the pre-recycle pipeline.

The pre-recycle pipeline converts the suspended events back to EDR format and sends the EDRs to the outcollect rating pipeline input directory.

Note:

The outcollect rating pipeline input directory also contains new roaming EDRs sent from the splitter pipeline.

The outcollect rating pipeline rates the recycled EDRs and newly arriving EDRs and generates a new outcollect TAP file. See "How Visiting Subscribers' Roaming CDRs Are Rated" for more information.

The outcollect rating pipeline notifies the Event Handler by sending it the EVT_OUTPUT_FILE_READY event. Upon receiving this event notification, the Event Handler launches the move_outcollectTap.pl script to copy the outcollect TAP file into the common directory (where all network operator outcollect TAP files are stored until settlement events have been created) and to move the original outcollect TAP file to the settlement pipeline input directory for creating settlement events. See "About Settling Roaming Charges" for more information.

Backing Out the Balance Impacts for the Rejected TAP Files and Records

The RAP processing pipeline creates an ASCII file that specifies the extraction criteria for extracting settlement events from the BRM database associated with the rejected outcollect TAP files and records.

For rejected TAP files, the ASCII file is created with a single record with the following information:

  • Outcollect TAP file sequence number

  • Network operator sending the TAP file

  • Network operator receiving the TAP file

For rejected TAP records, an ASCII file is created that contains a record for each rejected TAP record. Each record contains the following information:

  • Outcollect TAP file sequence number

  • Network operator sending the TAP file

  • Network operator receiving the TAP file

  • MSISDN

  • IMSI

  • Call event start timestamp

To back out the settlement event balance impacts (applied to the roaming partner's account when the outcollect TAP file was originally created), you manually run the Event Extraction Manager and specify the ASCII file in the input parameter. Event Extraction Manager uses the information in the ASCII file to extract the settlement events from the BRM database and copies the event data to an output file in the standard BRM input format.

The backout pipeline processes the Event Extraction output file and creates shadow events to negate the balance impacts of the settlement events. The output module writes the shadow events to an output file using RE Loader output grammar. You use RE Loader to load the shadow events into the BRM database.

If the backout pipeline is unable to process the Event Extraction output file, it suspends the entire file. Using Suspense Management Center, you can resubmit the file for processing.

For more information about Event Extraction Manager, see "pin_event_extract" in BRM Setting Up Pricing and Rating.

For information on configuring the backout pipeline, see "Configuring the Backout Pipeline".

Including Country Codes in TAP Output Files

BRM maps the EDR container field DETAIL.CALLED_COUNTRY_CODE into the CalledCountryCode field in the output TAP file. To ensure that the CalledCountryCode field has a valid value in cases where the country code is not present in the EDR, you specify a default country code in the CalledCountryCode registry entry of the TAP outcollect pipelines.

The value of this entry is a three-character country code, such as USA or GBR, that specifies the destination country code for an international call. For example:

ifw.Pipelines.OutCollectPipeline.CalledCountryCode = USA