This chapter describes how Oracle Communications Billing and Revenue Management (BRM) finds dropped calls and continuation calls.
Before reading this document, you should be familiar with the following concepts:
BRM discounting. See "About Discounts" in BRM Configuring Pipeline Rating and Discounting.
BRM prepaid authentication, authorization, and accounting (AAA). See "Understanding Prepaid AAA".
A customer's phone call may terminate unexpectedly for a variety of technical reasons, such as the mobile phone moving out of the wireless network's range or network interference. The customer may then make another call to the same phone number to resume the connection.
You can use the BRM dropped calls feature to identify when a customer's call is dropped (called a dropped call) and then resumed again through a subsequent call (called a continuation call). This allows you to compensate the customer for any inconvenience by discounting the dropped call, discounting the continuation call, or granting a credit to the customer.
BRM identifies dropped calls by reading the termination cause applied by the network switch and specified in the event data record (EDR) or event. You specify which termination causes qualify as a dropped call by using the pin_telco_aaa_params.xml file (real-time rating) or the FCT_DroppedCall registry entries (batch rating).
For more information, see the following:
For real-time rating, see "Specifying the Termination Causes for Dropped Calls".
For batch rating, see "Configuring Batch Rating to Find Dropped Calls and Continuation Calls".
BRM identifies continuation calls by using the following criteria:
The call time: Continuation calls must occur within a specified time frame after the dropped call. You can specify a maximum time interval for each service type that you support. If you do not specify a value, there is no time limit as long as both calls occur within the same billing cycle.
The call's placement after the dropped call: Continuation calls must occur within a specified number of calls after the dropped call. For example, you can specify that BRM checks only the customer's first call after the dropped call. If you do not specify a value, BRM checks all calls made by the customer.
The called party number: You can specify whether continuation calls must be to the same called number as the dropped call or if calls to other numbers can be continuation calls. If you do not specify a value, continuation calls must be to the same called number as the dropped call.
You set the above criteria by creating a service-level extended rating attribute (ERA). See "Creating the Dropped Calls ERA".
You can configure BRM to use additional criteria for finding continuation calls by rewriting a policy opcode (real-time rating) or by using the FCT_DroppedCall registry entries (batch rating). For more information, see the following:
For real-time rating, see "Specifying the Rules for Finding Continuation Calls".
For batch rating, see "Configuring Batch Rating to Find Dropped Calls and Continuation Calls".
During batch rating, the pipeline checks EDRs to see if they meet the criteria for a dropped call. When an EDR meets the criteria, the pipeline flags it as a dropped call and stores configuration information about the dropped call in internal pipeline memory. The pipeline then checks the caller's subsequent calls to determine whether they meet the criteria for a continuation call. When a call meeting the criteria is found, the pipeline adds to the EDR a continuation call flag and information about the dropped call, such as the dropped call's duration.
The batch rating process uses the FCT_DroppedCall pipeline module to detect and flag dropped calls and continuation calls. You use the module's registry entries to specify the following:
The EDR field and values used to identify dropped calls.
(Optional) The EDR fields used to identify continuation calls.
(Optional) The dropped call EDR fields to add to continuation calls.
General connection parameters, such as the name and location of the dropped calls data file.
You use FCT_DroppedCall in the rating pipeline, the rerating pipeline, and the recycling pipeline. See "FCT_DroppedCall" in BRM Configuring Pipeline Rating and Discounting.
When a phone call ends, the network switch records the termination cause in the customer's call details record (CDR). The BRM input grammar file maps this termination cause to the DETAIL.CALL_COMPLETION_INDICATOR EDR field. You specify which EDR field values qualify as a dropped call by using the FCT_DroppedCall registry entries.
Note:
FCT_DroppedCall uses the termination cause specified in the DETAIL.CALL_COMPLETION_INDICATOR EDR field by default. You can configure the module to use criteria from a different EDR field.To identify dropped calls, the FCT_DroppedCall module performs these tasks:
Checks whether there is a valid dropped call service-level ERA associated with the service.
If there is an ERA, FCT_DroppedCall proceeds to the next step.
If there is not an ERA, the module sets the DETAIL.DROPPED_CALL_STATUS EDR field to 0.
Determines whether the EDR meets the criteria specified in the registry file. If it meets the criteria, the module flags the call as a dropped call by setting the DETAIL.DROPPED_CALL_STATUS EDR field to 1. It also writes to pipeline memory a list of configurable field values.
Writes the in-memory data to the dropped calls data file. See "About the Dropped Calls Data File".
After identifying a dropped call, FCT_DroppedCall checks the customer's subsequent EDRs to determine if any of them meet the criteria for a continuation call.
When examining an EDR, the module determines whether it meets the criteria specified in the dropped call ERA and FCT_DroppedCall registry entries, and then performs the following:
If the call meets the criteria, the module sets the EDR's DETAIL.DROPPED_CALL_STATUS field to 2 to indicate that it is a continuation call.
If the call meets the criteria and the DETAIL.DROPPED_CALL_STATUS EDR field is already set to 1, the module changes the EDR field to 3 to indicate that it is both a dropped call and a continuation call.
If the call does not meet the criteria and exceeds either the maximum call time or the maximum number of intermediate calls, the module sets the EDR's DETAIL.DROPPED_CALL_STATUS field to 4 to indicate that it didn't meet the criteria for a dropped call or a continuation call.
If the call does not meet the criteria, but does not exceed both the maximum call time and maximum number of intermediate calls, the module:
Increments a counter stored in memory that tracks the number of intermediate calls.
Records the call's starting timestamp.
Sets the EDR's DETAIL.DROPPED_CALL_STATUS field to 4 to indicate that it didn't meet the criteria for a dropped call or a continuation call.
Examines the customer's next call.
At the end of each transaction, the module writes the in-memory data to the dropped calls data file. See "About the Dropped Calls Data File".
FCT_DroppedCall stores in internal pipeline memory information about a dropped call, including the EDR fields for identifying a continuation call and the list of EDR fields to attach to the continuation call EDR. When the module finds the matching continuation call, it closes the dropped call and removes information about the dropped call from memory.
At the end of each transaction, the module backs up the in-memory data to a dropped calls data file. This enables you to reload the data into memory if the system crashes or restarts.
FCT_DroppedCall updates the data file at the end of each transaction to match the information stored in memory, such as:
Adding any new dropped calls written to memory.
Adding the starting timestamp for the last processed intermediate call.
Updating a dropped call's counter of intermediate calls.
Deleting any dropped calls that were removed from memory.
You configure how often to purge old calls from memory and the data file by using the RemoveLimit semaphore file entry. See "FCT_DroppedCall" in BRM Configuring Pipeline Rating and Discounting and "Purging Old Call Data from Memory".
Note:
Account Migration Manager (AMM) does not move the dropped calls data file between pipelines. If an account is migrated, you must manually move any associated dropped call entries to the new pipeline.The pipeline rejects some EDRs because they fail validation or because a module added an error code. This can prevent an EDR from being identified as a dropped call or a continuation call, depending on where in the pipeline the EDR is rejected.
Table 45-1 describes how rejected EDRs affect FCT_DroppedCall's ability to detect dropped calls and continuation calls.
Table 45-1 Rejected EDR Affect on FCT_DroppedCall
| EDR Type | Rejected Before or After FCT_DroppedCall | Description |
|---|---|---|
|
Dropped call EDR |
Before |
The EDR is not identified as a dropped call. Any subsequent calls are not identified as a continuation call. |
|
Dropped call EDR |
After |
The EDR is identified as a dropped call and stored in memory. The module can still find the call's associated continuation call. During the recycling process, FCT_DroppedCall does not re-evaluate any EDR that was already processed successfully by the module. Therefore, the module does not re-evaluate the dropped call EDR. |
|
Continuation call EDR |
Before |
The EDR is not initially tagged as a continuation call. During the recycling process, the rejected EDR is reprocessed and can be identified as a continuation call. Note: The module flags the first EDR it processes that meets the criteria for a continuation call. Therefore, if multiple EDRs meet the criteria, the module may flag a different EDR as the continuation call. |
|
Continuation call EDR |
After |
The EDR is tagged as a continuation call. During the recycling process, FCT_DroppedCall does not re-evaluate any EDR that was already processed successfully by the module. Therefore, the module does not re-evaluate the continuation call EDR. |
During the rerating process, the FCT_DroppedCall module re-evaluates each EDR to determine whether it qualifies as a dropped call or a continuation call, using the same method it did during the rating process.
FCT_DroppedCall can find and flag continuation calls during the rerating process only if both the dropped call EDR and the continuation call EDR are included in the rerating job. To ensure that both EDRs are included in the rerating job, configure your rerating trigger to check for continuation calls. If a continuation call is found, the trigger should backdate the start time to include the dropped call.
To support dropped calls and continuation calls during the rerating process, add the FCT_DroppedCall module to your batch rerating pipeline and real-time rerating pipeline.
For more information about rerating, see "About Rerating Pipeline-Rated Events" in BRM Setting Up Pricing and Rating.
During real-time rating, BRM stores information about ongoing prepaid sessions in /active_session objects. When the call ends, BRM records the termination cause and determines whether the call qualifies as a dropped call. When a call meets the criteria, BRM flags it as a dropped call.
When BRM authorizes or reauthorizes subsequent prepaid sessions, it determines whether the session qualifies as a continuation call by comparing the current session with the caller's previous call sessions. If the call meets the criteria, it is flagged as a continuation call.
BRM uses the PCM_OP_TCF_AAA_DETECT_CONTINUATION_CALL helper opcode and the PCM_OP_TCF_AAA_POL_MATCH_CONTINUATION_CALL policy opcode to detect and flag continuation calls.
When a prepaid AAA call ends, real-time rating performs these tasks to find and tag dropped calls:
Records the call's termination cause in the /active_session object's PIN_FLD_TERMINATE_CAUSE field.
Determines whether the call qualifies as a dropped call by comparing the termination cause with the value specified in the /config/aaa/gsm/xxx object's PIN_FLD_DROPPED_CALL_TERMINATE_CAUSE field:
If it qualifies as a dropped call, BRM flags the call as a dropped call by setting the /active_session object's PIN_FLD_CALL_TYPE field to 1.
If it qualifies as a dropped call and the call is already flagged as a continuation call, BRM flags the call as both a dropped call and a continuation call by setting the /active_session object's PIN_FLD_CALL_TYPE field to 3.
If it does not qualify as a dropped call, BRM does not modify the PIN_FLD_CALL_TYPE field.
Real-time rating performs these tasks during the prepaid AAA process to find and tag continuation calls:
The AAA opcode calls the PCM_OP_TCF_AAA_DETECT_CONTINUATION_CALL helper opcode at the TAG_SESSION processing stage.
PCM_OP_TCF_AAA_DETECT_CONTINUATION_CALL searches for the dropped call ERA associated with the service. If the ERA is not present, the opcode returns to the calling opcode.
PCM_OP_TCF_AAA_DETECT_CONTINUATION_CALL determines whether the call is already flagged as a continuation call:
If it is not flagged, the helper opcode continues to the next step.
If it is already flagged and the calling opcode is PCM_OP_TCF_AAA_STOP_ACCOUNTING, the helper opcode optionally deletes any redundant /active_session objects from memory and then returns to the calling opcode.
If it is already flagged and the calling opcode is any opcode other than PCM_OP_TCF_AAA_STOP_ACCOUNTING, the helper opcode returns to the calling opcode.
PCM_OP_TCF_AAA_DETECT_CONTINUATION_CALL searches through the existing /active_session objects in memory to find all /active_session objects with the same service type and caller number as the current call.
PCM_OP_TCF_AAA_DETECT_CONTINUATION_CALL sorts the /active_session objects that met the criteria by PIN_FLD_CREATED_T, in decreasing order.
PCM_OP_TCF_AAA_DETECT_CONTINUATION_CALL loops through the sorted /active_session objects to find ones that match the dropped call termination cause.
At the MATCH_CONTINUOUS_CALL processing stage, PCM_OP_TCF_AAA_DETECT_CONTINUATION_CALL sends the current call, the dropped call, the dropped call ERA, the /config/aaa/gsm/xxx object, billing cycle information, and the list of intermediate /active_session objects to the policy opcode specified in the /config/opcodemap/tcf object. By default, /config/opcodemap/tcf is configured to call PCM_OP_TCF_AAA_POL_MATCH_CONTINUATION_CALL.
Note:
You can change which policy opcodes are called at the MATCH_CONTINUOUS_CALL processing stage by using the pin_config_opcodemap_tcf configuration file. See "Customizing the Criteria for Finding Continuation Calls".PCM_OP_TCF_AAA_POL_MATCH_CONTINUATION_CALL checks whether the current /active_session object meets the criteria specified in the dropped call ERA.
PCM_OP_TCF_AAA_POL_MATCH_CONTINUATION_CALL returns to PCM_OP_TCF_AAA_DETECT_CONTINUATION_CALL the PIN_FLD_RESULT field set to one of the following:
0 to indicate that the current call is not a continuation call.
1 to indicate that the current call is a continuation call.
2 to indicate that the current call is not a continuation call because it exceeds the maximum time duration or maximum number of intermediate calls.
PCM_OP_TCF_AAA_DETECT_CONTINUATION_CALL performs one of the following, depending on the value of the PIN_FLD_RESULT flist field:
If PIN_FLD_RESULT is set to 0, the opcode flags the current call's /active_session object as a normal call by setting the PIN_FLD_CALL_TYPE field to 0.
If PIN_FLD_RESULT is set to 1, the opcode flags the current call's /active_session object as a continuation call by setting the PIN_FLD_CALL_TYPE field to 2. It also adds the duration of the dropped call to the PIN_FLD_DROPPED_CALL_QUANTITY field, and the POID of the dropped call's /active_session object to the PIN_FLD_DROPPED_CALL_ASO_POID field.
If PIN_FLD_RESULT is set to 2, the opcode flags the current call's /active_session object as a normal call by setting the PIN_FLD_CALL_TYPE field to 0. It also stops iterating the /active_session objects.
When performing prepaid AAA, BRM stores information about on-going sessions in /active_session objects. When the prepaid session ends, BRM transfers the information to an /event/session object and either keeps or deletes the /active_session object, depending on how the DeletedFlag field is set in the /config/aaa/gsm/xxx object.
When configured for dropped calls, BRM automatically keeps /active_session objects for any service type that supports the dropped calls feature. This allows BRM to search through previous call sessions. You specify which services support the dropped calls feature in the service-specific /config/aaa/gsm/xxx object. See "Specifying the Termination Causes for Dropped Calls".
When a prepaid session ends, BRM deletes any redundant /active_session objects to reduce disk space. That is, BRM searches through the /active_session objects and deletes objects that meet all of these criteria:
Have the same caller number as the current call.
Have the same service type as the current call.
Have any of the following:
A timestamp that exceeds the maximum duration specified in the dropped call ERA.
A call counter that surpasses the maximum number of intermediate calls specified in the dropped call ERA.
A billing cycle that is different than that of the current call.
If the current call is flagged as a continuation call, BRM also deletes the dropped call, the continuation call, and all intermediate calls that aren't an unidentified dropped call themselves.
You can compensate customers for dropped calls by doing one of the following:
Discounting the dropped call, based on the call termination value.
Discounting the continuation call, based on the duration of the dropped call.
Granting a credit to the customer that can be applied in the current billing cycle or the next billing cycle.
You specify how to compensate customers by using BRM discounting. During the discounting process, BRM determines whether the event is a dropped call or a continuation call and then applies the appropriate discount or credit.
For more information about BRM discounting, see "About Discounts" in BRM Configuring Pipeline Rating and Discounting.