This chapter explains how the Oracle Communications Billing and Revenue Management (BRM) API processes prepaid authentication, authorization, and accounting (AAA) requests from external networks.
The main opcodes for processing prepaid AAA requests are the Services Framework AAA opcodes, which are generic framework opcodes that perform AAA operations common to all service types. Information is passed to these opcodes through either a service-specific manager, such as GSM AAA Manager, or a gateway application. For more information about the Services Framework, see "About Performing AAA for Prepaid Services".
You can use the BRM API to perform the following operations:
Authenticate prepaid customers. See "How BRM Authenticates Prepaid Customers".
Authorize customers to use a prepaid service. See "How BRM Authorizes Users to Access Prepaid Services".
If you enabled in-session notifications, provide such notifications in the AAA responses to your network connectivity application. See "Providing In-Session Notifications for Network Connectivity Applications".
Reauthorize customers to continue a prepaid session. See "How BRM Reauthorizes Prepaid Services".
If you enabled in-session notifications, provide such notifications in the AAA responses to your network connectivity application. See "Providing In-Session Notifications for Network Connectivity Applications".
Update prepaid sessions and then reauthorize usage. See "How BRM Updates and Reauthorizes Prepaid Sessions".
If you enabled in-session notifications, provide such notifications in the AAA responses to your network connectivity application. See "Providing In-Session Notifications for Network Connectivity Applications".
Cancel authorization. See "How BRM Cancels Prepaid Service Authorizations".
Manage prepaid sessions while they are in progress. See "How BRM Manages Prepaid Sessions".
For more information about prepaid authentication, see "About Authenticating Prepaid Customers".
The main opcode for authenticating prepaid customers is PCM_OP_TCF_AAA_AUTHENTICATE. You control whether BRM authenticates prepaid customers in Password Authentication Protocol (PAP) mode or Challenge-Handshake Authentication Protocol (CHAP) mode by passing the optional PIN_FLD_PASSWORD input flist field. If this field is passed in, BRM authenticates in PAP mode. If the field is not passed in, BRM authenticates in CHAP mode.
BRM authenticates users for prepaid services as follows:
PCM_OP_TCF_AAA_AUTHENTICATE calls the PCM_OP_ACT_FIND_VERIFY opcode to validate the user's identification. The MSID is used as the login field for PCM_OP_ACT_FIND_VERIFY.
PCM_OP_ACT_FIND_VERIFY calls the PCM_OP_ACT_FIND opcode to locate the customer's account information. The opcode returns the customer's /account and /service objects.
If the service type is not provided in the input flist, PCM_OP_ACT_FIND locates all the matching service instances of the mobile station ID (MSID) as the login, depending on whether you use a single-schema, a multischema, or an Oracle In-Memory Database (IMDB) Cache-enabled BRM system.
PCM_OP_ACT_FIND_VERIFY calls the PCM_OP_ACT_POL_SPEC_VERIFY policy opcode to retrieve the list of authentication checks to perform. The policy opcode returns the list of verification checks.
PCM_OP_ACT_FIND_VERIFY performs all checks specified by the policy opcode and returns to PCM_OP_TCF_AAA_AUTHENTICATE either success or failure.
PCM_OP_TCF_AAA_AUTHENTICATE returns to the caller either success or failure and, if CHAP authentication was used, the unencrypted password.
For more information about prepaid authorization, see "About Authorizing Prepaid Usage".
The main opcode for authorizing prepaid services is PCM_OP_TCF_AAA_AUTHORIZE. If your system is configured to handle in-session notifications from BRM (that is, the piggyback business parameter is enabled), this opcode appends in-session notifications to the responses it returns to the calling network connectivity application. See "Providing In-Session Notifications for Network Connectivity Applications" for more information.
BRM authorizes prepaid services as follows:
Note:
If you configure lightweight authorization, BRM authorizes prepaid services differently. See "How BRM Authorizes Users to Access Services When Lightweight Authorization Is Configured".PCM_OP_TCF_AAA_AUTHORIZE calls the PCM_OP_ACT_FIND opcode to locate the customer's account information. The opcode returns the customer's /account and /service objects.
If the service type is not provided in the input flist, PCM_OP_ACT_FIND opcode locates all the matching service instances of the MSID as the login, depending on whether you use a single-schema, a multischema, or an Oracle IMDB Cache-enabled BRM system.
At the SEARCH_SESSION stage, PCM_OP_TCF_AAA_AUTHORIZE calls the helper opcode specified in the /config/opcodemap/tcf object. The helper opcode returns a search template for finding session objects.
PCM_OP_TCF_AAA_AUTHORIZE uses the template to search for duplicate sessions. If the opcode finds a session with the same active session ID, authorization fails.
At the PREP_INPUT stage, PCM_OP_TCF_AAA_AUTHORIZE calls the helper opcode specified in the /config/opcodemap/tcf object to aggregate service-specific data. The helper opcode returns a service-specific input flist.
For policy-driven charging, checks to see if the request quota exceeds the available amount. See "Readjustment of Quota During Prepaid Authorization for Policy-Driven Charging". Also sets up an offer profile threshold breach notification if a threshold was breached in the offer profile for the service POID and account POID. See "About the PCM_OP_BAL_POL_APPLY_MULTI_BAL_IMPACTS Policy Opcode" in BRM Setting Up Pricing and Rating.
At the VALIDATE_LIFECYCLE stage, PCM_OP_TCF_AAA_AUTHORIZE calls the helper opcode specified in the /config/opcodemap/tcf object to validate the request if the service uses a custom life cycle. If validation succeeds, the authorization process continues. If validation fails, the request is denied.
PCM_OP_TCF_AAA_AUTHORIZE calls the PCM_OP_ACT_POL_SCALE_MULTI_RUM_QUANTITIES policy opcode to scale quantities for multi-RUM requests. See "Scaling Quantities for Prepaid Authorization Requests" for more information.
PCM_OP_TCF_AAA_AUTHORIZE passes the service-specific input flist to the PCM_OP_ACT_AUTHORIZE opcode.
PCM_OP_ACT_AUTHORIZE calls the PCM_OP_ACT_POL_PRE_AUTHORIZE policy opcode, which can be used to customize the authorization process.
If its input flist contains an /active_session type-only POID instead of an /active_session POID, PCM_OP_ACT_AUTHORIZE calls the PCM_OP_ASM_CREATE_ACTIVE_SESSION opcode to create an /active_session object (or a subclass of it).
PCM_OP_ACT_AUTHORIZE calls the PCM_OP_RESERVE_CREATE opcode to authorize the requested service and reserve resources for it. For multi-RUM requests, the input flist for PCM_OP_RESERVE_CREATE optionally includes a separate PIN_FLD_RUM_MAP array for each RUM. This array includes the minimum quantity for each RUM.
Note:
If you have enabled the Piggyback business parameter to generate in-session notifications, PCM_OP_ACT_AUTHORIZE and PCM_OP_RESERVE_CREATE append credit threshold breach information to their responses. For more information on enabling Piggyback, see "Enabling In-Session Notifications".To receive credit threshold breach information when you call PCM_OP_ACT_AUTHORIZE or PCM_OP_RESERVE_CREATE directly from testnap or a custom application, set the PIN_FLD_PIGGYBACK_FLAG in the input flist when you call the specific opcode. See "About Setting Up Custom Applications to Receive Credit Threshold Breach Information" for more information.
PCM_OP_RESERVE_CREATE does one of the following:
For an amount-based request, compares the requested amount against the account's resources. Depending on the results of the comparison, PCM_OP_RESERVE_CREATE takes one of the actions listed in Table 7-1:
Table 7-1 Actions Taken by PCM_OP_RESERVE_CREATE
| Comparison Result | PCM_OP_RESERVE_CREATE Action |
|---|---|
|
Resources are greater than or equal to the requested amount. |
|
|
Resources are less than the requested amount but greater than or equal to the input PIN_FLD_MIN_QUANTITY value. |
|
|
Resources are less than the input PIN_FLD_MIN_QUANTITY value. |
|
For a quantity-based request, calls PCM_OP_ACT_USAGE in CALC_ONLY mode to determine whether the account's resources can cover the requested quantity or quantities. See "How Rating Works" in BRM Setting Up Pricing and Rating.
If the full quantity or quantities cannot be covered, BRM determines the maximum resource amounts that can be reserved. See "Credit Limit Checks during Prepaid Authorization" for more information.
If you enabled in-session notifications, PCM_OP_ACT_USAGE is called with PIN_FLD_PIGGGYBACK_FLAG set to 1 (enabled). PCM_OP_ACT_USAGE calculates the credit threshold breaches and returns any breach information in its output flist. See "How BRM Provides Credit Threshold Breach Notifications" for more information.
Based on the results returned by PCM_OP_ACT_USAGE, PCM_OP_RESERVE_CREATE takes one of the actions listed in Table 7-2:
Table 7-2 Actions Taken by PCM_OP_RESERVE_CREATE
| PCM_OP_ACT_USAGE Result | PCM_OP_RESERVE_CREATE Action |
|---|---|
|
Single-RUM The account's resources cover the requested quantity. Multi-RUM The account's resources cover all requested quantities. |
|
|
Single-RUM The account's resources do not cover the full requested quantity but do cover at least the minimum quantity for the RUM. Multi-RUM The account's resources cover the minimum quantity for all RUMs, but the full requested quantity cannot be covered for at least one RUM. |
|
|
Single-RUM The available resources cover less than the minimum quantity for the RUM. Multi-RUM The available resources cover less than the minimum quantity for at least one RUM. |
|
|
Single-RUM The requested quantity is less than the minimum for the RUM. Multi-RUM Any requested quantity is less than the minimum quantity for that RUM. |
|
|
Single-RUM No resources available. Multi-RUM No resources available for all RUMs. |
|
Based on the results passed in from PCM_OP_RESERVE_CREATE, PCM_OP_ACT_AUTHORIZE takes one of the actions listed in Table 7-3:
Table 7-3 Actions Taken by PCM_OP_ACT_AUTHORIZE
| PCM_OP_RESERVE_CREATE Result | PCM_OP_ACT_AUTHORIZE Action |
|---|---|
|
PIN_RESERVATION_SUCCESS |
|
|
PIN_RESERVATION_INSUFFICIENT_FUNDS |
|
|
PIN_RESERVATION_NO_FUNDS |
|
|
PIN_RESERVATION_INSUFFICIENT_RATED_QTY |
|
|
PIN_RESERVATION_INVALID_REQUESTED_QTY |
|
When the PCM_OP_ASM_UPDATE_ACTIVE_SESSION opcode is called with PIN_FLD_CREDIT_THRESHOLDS in its input flist, it updates the /active_session object with any credit threshold breach information.
If this is the first usage session of a resource whose validity period is based on first usage and the SetFirstUsageInSession business parameter is enabled, PCM_OP_BAL_APPLY_MULTI_BAL_IMPACTS is called to set the start time of the resource's validity period.
Note:
By default, SetFirstUsageInSession is disabled, and the start time of the validity period is set at the end of the first usage session to the end time of that session. For more information, see "About Setting Resource Validity Periods Based on First Usage" in BRM Setting Up Pricing and Rating.PCM_OP_TCF_AAA_AUTHORIZE calls the PCM_OP_ACT_POL_POST_AUTHORIZE policy opcode to make any specified customizations to its output flist before returning the flist to the calling opcode. By default, the policy opcode drops the PIN_FLD_RESULTS field from the flist.
If the Piggyback business parameter is enabled, PCM_OP_ACT_AUTHORIZE calls the PCM_OP_TCF_AAA_POL_POST_PROCESS policy opcode to set up the required in-session notifications. See "How BRM Provides In-Session Notifications" for more information.
The PCM_OP_ACT_AUTHORIZE opcode, used during the BRM default prepaid authorization, authorizes a single service for a single customer at a time. The PCM_OP_ACT_MULTI_AUTHORIZE opcode offers the option of rating and authorizing multiple prepaid services with a single call. This opcode takes an array of services and a mode of operation as input and acts on them all within the same transaction. To take advantage of this option, you must write a custom program to replace the default BRM prepaid access authorization opcode flow using PCM_OP_ACT_MULTI_AUTHORIZE instead of PCM_OP_ACT_AUTHORIZE.
Note:
BRM does not provide in-session notifications when it authorizes multiple services with a single call. An in-session notification is specific to a single service.For details on the default prepaid authorization process, see "How BRM Authorizes Users to Access Prepaid Services".
For details on writing a custom program, see "About Customizing BRM" and "Writing a Custom Facilities Module" in BRM Developer's Guide.
The PCM_OP_ACT_AUTHORIZE opcode, used during the BRM default prepaid authorization, reserves the resources that you pass in. The PCM_OP_ACT_MULTI_AUTHORIZE opcode offers the option of performing CALC_ONLY rating of the requested balances for each service passed in. To take advantage of this option, you must write a custom program to replace the default BRM prepaid access authorization opcode flow using PCM_OP_ACT_MULTI_AUTHORIZE instead of PCM_OP_ACT_AUTHORIZE.
Note:
BRM does not provide in-session notifications when it authorizes multiple services with a single call. An in-session notification is specific to a single service.For details on the default prepaid authorization process, see "How BRM Authorizes Users to Access Prepaid Services".
For details on writing a custom program, see "About Customizing BRM" and "Writing a Custom Facilities Module" in BRM Developer's Guide.
The default BRM prepaid authorization works exclusively with accounts and balances contained in a BRM database. The PCM_OP_ACT_MULTI_AUTHORIZE opcode offers the option of performing CALC_ONLY rating based on monetary balances that you pass in, regardless of whether they originated in a BRM database.
Note:
BRM does not provide in-session notifications when it authorizes multiple services with a single call. An in-session notification is specific to a single service.PCM_OP_ACT_MULTI_AUTHORIZE calculates whether the account has sufficient resources for the requested service and returns the result. It treats monetary and non-monetary resources differently:
For non-monetary resources, this opcode makes the calculation using the available balances in the BRM database.
For monetary resources, this opcode makes the calculation using the available balances passed in.
To take advantage of this option, you must write a custom program to replace the default BRM prepaid access authorization opcode flow. Your application must use PCM_OP_ACT_MULTI_AUTHORIZE instead of PCM_OP_ACT_AUTHORIZE.
For details on the default prepaid authorization process, see "How BRM Authorizes Users to Access Prepaid Services".
For details on writing a custom program, see "About Customizing BRM" and "Writing a Custom Facilities Module" in BRM Developer's Guide.
For more information about prepaid reauthorization, see "About Reauthorizing Prepaid Usage".
The main opcode for reauthorizing prepaid services is PCM_OP_TCF_AAA_REAUTHORIZE.
For policy-driven charging sessions, the network connectivity application provides the consumed quota in the reauthorization request. If BRM calculates that a threshold breach has occurred, it sets up an offer profile threshold breach event notification and calls the Payload Generator external module. (This application collects events, generates the data necessary to publish business events, and sends the data to the EAI-based (enterprise application integration) applications in your enterprise.) For more information, see "About the Data Synchronization Process" in BRM Synchronization Queue Manager and "Integrating BRM with Enterprise Applications" in BRM Developer's Guide.
For in-session notifications generated because you enabled the Piggyback business parameter, this opcode returns request and service-related information required by the network connectivity application. See "Providing In-Session Notifications for Network Connectivity Applications".
BRM reauthorizes prepaid sessions as follows:
Note:
If you configure lightweight authorization, BRM reauthorizes prepaid services differently. See "How BRM Reauthorizes Prepaid Services When Lightweight Authorization Is Configured".PCM_OP_TCF_AAA_REAUTHORIZE calls the PCM_OP_ACT_FIND opcode to locate the customer's account information. The opcode returns the customer's /account and /service objects.
If the service type is not provided in the input flist, the opcode finds all the matching service instances of the MSID as the login, depending on whether you use a single-schema, a multischema, or an Oracle IMDB Cache-enabled BRM system.
At the SEARCH_SESSION stage, PCM_OP_TCF_AAA_REAUTHORIZE calls the helper opcode specified in the /config/opcodemap/tcf object. The helper opcode returns a search template for finding session objects.
PCM_OP_TCF_AAA_REAUTHORIZE uses the template to search for the /active_session object.
If the object is found, the opcode calls the appropriate PREP_INPUT helper opcode to prepare a service-specific input flist and then passes the input flist to the PCM_OP_ACT_REAUTHORIZE opcode to reauthorize the call.
If the object is not found, the opcode calls the appropriate PREP_INPUT helper opcode to prepare a service-specific input flist and then passes the input flist to the PCM_OP_ACT_AUTHORIZE opcode to authorize the session with the given information. See "How BRM Authorizes Users to Access Prepaid Services".
PCM_OP_ACT_REAUTHORIZE determines whether the session's /active_session object (PIN_FLD_POID in the input flist), /reservation_active object (PIN_FLD_RESERVATION_OBJ in the input flist), and the /config/reserve object exist.
If the objects exist, the opcode performs the next step.
If the objects do not exist, the opcode calls PCM_OP_ACT_AUTHORIZE to perform a session authorization. See "How BRM Authorizes Users to Access Prepaid Services" for more information.
Note:
If Oracle IMDB Cache shuts down after a prepaid session begins, the session's /active_session and /reservation_active objects will no longer exist.If the /config/reserve object contains a resource ID, this opcode retrieves the balances for all the resources associated with the resource ID, the associated offer profiles for the service POID and account POID. It reduces the consumed quota by the consumed reserved amount in the BALANCES array, and determines if the requested quota exceeds the amount available. If so, it readjusts the quota to the amount that is available.
PCM_OP_TCF_AAA_REAUTHORIZE calls the PCM_OP_ACT_POL_SCALE_MULTI_RUM_QUANTITIES policy opcode to scale quantities for multi-RUM requests. See "Scaling Quantities for Prepaid Authorization Requests" for more information for more information.
PCM_OP_ACT_REAUTHORIZE calls the PCM_OP_ACT_POL_PRE_REAUTHORIZE policy opcode, which can be used to customize the reauthorization process.
PCM_OP_ACT_REAUTHORIZE calls the PCM_OP_RESERVE_EXTEND opcode to reauthorize the requested service and extend its resource reservations. For multi-RUM requests, the input flist for PCM_OP_RESERVE_EXTEND optionally includes a separate PIN_FLD_RUM_MAP array for each RUM. This array includes the minimum quantity for each RUM.
Note:
If you have enabled the Piggyback business parameter to generate in-session notifications, PCM_OP_ACT_REAUTHORIZE and PCM_OP_RESERVE_EXTEND append credit threshold breach information to their responses. For more information on enabling Piggyback, see "Enabling In-Session Notifications" for more information.To receive credit threshold breach information when you call PCM_OP_ACT_REAUTHORIZE or PCM_OP_RESERVE_EXTEND directly from testnap or a custom application, set the PIN_FLD_PIGGYBACK_FLAG in the input flist when you call the specific opcode. See "About Setting Up Custom Applications to Receive Credit Threshold Breach Information" for more information.
PCM_OP_RESERVE_EXTEND does the following:
For an amount-based request, compares the requested amount against the account's resources. Depending on the results of the comparison, PCM_OP_RESERVE_EXTEND takes one of the actions listed in Table 7-4:
Table 7-4 Actions Taken by PCM_OP_RESERVE_EXTEND
| Comparison Result | PCM_OP_RESERVE_EXTEND Action |
|---|---|
|
Resources are greater than or equal to the requested amount. |
|
|
Resources are less than the requested amount but greater than or equal to the input PIN_FLD_MIN_QUANTITY value. |
|
|
Resources are less than the input PIN_FLD_MIN_QUANTITY value. |
|
For a quantity-based request,
If the request is associated with a policy-driven charging session, the PCM_OP_RESERVE_EXTEND opcode updates the consumed reservation amount for the service in the /reservation and /balance_group objects.
It calls PCM_OP_ACT_USAGE in CALC_ONLY mode to determine whether the account's resources can cover the requested quantity or quantities. See "How Rating Works" in BRM Setting Up Pricing and Rating for more information.
If the full quantity or quantities cannot be covered, BRM determines the maximum resource amounts that can be reserved. See "Credit Limit Checks during Prepaid Authorization" for more information.
If you have enabled the Piggyback business parameter to generate in-session notifications, PCM_OP_ACT_USAGE is called with PIN_FLD_PIGGGYBACK_FLAG set to 1 (enabled). PCM_OP_ACT_USAGE calculates the credit threshold breaches and returns any breach information in its output flist. See "How BRM Provides Credit Threshold Breach Notifications" for more information.
Based on the results returned by PCM_OP_ACT_USAGE, PCM_OP_RESERVE_EXTEND takes one of the following actions listed in Table 7-5:
Table 7-5 Actions taken by PCM_OP_RESERVE_EXTEND
| PCM_OP_ACT_USAGE Result | PCM_OP_RESERVE_EXTEND Action |
|---|---|
|
Single-RUM The account's resources cover the requested quantity. Multi-RUM The account's resources cover all requested quantities. |
|
|
Single-RUM The account's resources cover more than the currently reserved quantity but do not cover the full requested quantity. Multi-RUM The account's resources cover more than the currently reserved quantity for all RUMs, but do not cover the full requested quantity for at least one RUM. |
|
|
Single-RUM The available resources cover less than the minimum quantity for the RUM. Multi-RUM The available resources cover less than the minimum quantity for at least one RUM. |
|
|
Single-RUM The requested quantity is less than the minimum for the RUM. Multi-RUM Any requested quantity is less than the minimum quantity for that RUM. |
|
|
Single-RUM No resources available. Multi-RUM No resources available for all RUMs. |
|
Based on the results passed in from PCM_OP_RESERVE_EXTEND, PCM_OP_ACT_REAUTHORIZE takes one of the actions listed in Table 7-6:
Table 7-6 Actions Taken by PCM_OP_ACT_REAUTHORIZE
| PCM_OP_RESERVE_EXTEND Result | PCM_OP_ACT_REAUTHORIZE Action |
|---|---|
|
PIN_RESERVATION_SUCCESS |
|
|
PIN_RESERVATION_INSUFFICIENT_FUNDS |
|
|
PIN_RESERVATION_NO_FUNDS |
|
|
PIN_RESERVATION_INSUFFICIENT_RATED_QTY |
|
|
PIN_RESERVATION_INVALID_REQUESTED_QTY |
|
PCM_OP_ACT_REAUTHORIZE calls the PCM_OP_ACT_POL_POST_REAUTHORIZE policy opcode to make any specified customizations to its output flist before returning the flist to the calling opcode. By default, the policy opcode drops the PIN_FLD_RESULTS field from the flist.
If the Piggyback business parameter is enabled, PCM_OP_TCF_AAA_REAUTHORIZE calls the PCM_OP_TCF_AAA_POL_POST_PROCESS policy opcode to set up the required in-session notifications. See "How BRM Provides In-Session Notifications" for more information.
The main opcode for updating and reauthorizing prepaid sessions is PCM_OP_TCF_AAA_UPDATE_AND_REAUTHORIZE.
For in-session notifications generated because you enabled the Piggyback business parameter, this opcode returns request-related and service-related information required by the network connectivity application. See "Providing In-Session Notifications for Network Connectivity Applications".
BRM updates and reauthorizes prepaid sessions as follows:
PCM_OP_TCF_AAA_UPDATE_AND_REAUTHORIZE calls the PCM_OP_ACT_FIND opcode to locate the customer's account information. The opcode returns the customer's /account and /service objects.
If the service type is not provided in the input flist, PCM_OP_ACT_FIND opcode locates all the matching service instances of the MSID as the login, depending on whether you use a single-schema, a multischema, or an Oracle IMDB Cache-enabled BRM system.
PCM_OP_TCF_AAA_UPDATE_AND_REAUTHORIZE calls the PCM_OP_BAL_LOCK_RESERVATION_LIST opcode to find and lock the balance group's /reservation_list object. The opcode returns the POID of the /reservation_list object.
At the SEARCH_SESSION stage, PCM_OP_TCF_AAA_UPDATE_AND_REAUTHORIZE calls the helper opcode specified in the /config/opcodemap/tcf object. The helper opcode builds a search template for finding the /active_session object.
PCM_OP_TCF_AAA_UPDATE_AND_REAUTHORIZE uses the search template to find the /active_session object.
PCM_OP_TCF_AAA_UPDATE_AND_REAUTHORIZE calls the PCM_OP_ACT_UPDATE_SESSION opcode to update the account balance in the /active_session object.
PCM_OP_ACT_UPDATE_SESSION determines whether to update or create the /active_session object by checking the PIN_FLD_POID input flist field.
If the field contains a complete POID, the opcode calls the PCM_OP_ASM_UPDATE_ACTIVE_SESSION opcode to update the /active_session object's data and status. The opcode returns the POID of the updated /active_session object.
If the field contains a POID type only, the opcode calls the PCM_OP_ASM_CREATE_ACTIVE_SESSION opcode to create the /active_session object. The opcode returns the POID of the created /active_session object.
PCM_OP_TCF_AAA_UPDATE_AND_REAUTHORIZE retrieves the updated balance from the /active_session object.
PCM_OP_TCF_AAA_UPDATE_AND_REAUTHORIZE calls the PCM_OP_ACT_REAUTHORIZE opcode to reauthorize the prepaid session.
For policy-driven charging, checks to see if the request quota exceeds the available amount. See "Readjustment of Quota During Prepaid Authorization for Policy-Driven Charging". Also sets up an offer profile threshold breach notification if a threshold was breached in the offer profile for the service POID and account POID. See "About the PCM_OP_BAL_POL_APPLY_MULTI_BAL_IMPACTS Policy Opcode" in BRM Setting Up Pricing and Rating.
PCM_OP_ACT_REAUTHORIZE determines whether the session's /active_session object (PIN_FLD_POID in the input flist) and /reservation_active object (PIN_FLD_RESERVATION_OBJ in the input flist) exist.
If the objects do not exist, the opcode calls PCM_OP_ACT_AUTHORIZE to perform a session authorization. See "How BRM Authorizes Users to Access Prepaid Services".
Note:
If Oracle IMDB Cache shuts down after a prepaid session begins, the session's /active_session and /reservation_active objects will no longer exist.PCM_OP_TCF_AAA_UPDATE_AND_REAUTHORIZE calls the PCM_OP_ACT_POL_SCALE_MULTI_RUM_QUANTITIES policy opcode to scale quantities for multi-RUM requests. See "Scaling Quantities for Prepaid Authorization Requests" for more information.
PCM_OP_ACT_REAUTHORIZE calls the PCM_OP_ACT_POL_PRE_REAUTHORIZE policy opcode, which can be used to customize the reauthorization process.
PCM_OP_ACT_REAUTHORIZE calls PCM_OP_RESERVE_EXTEND to reauthorize the requested service and extend its resource reservations.
For multi-RUM requests, the input flist for PCM_OP_RESERVE_EXTEND optionally includes a separate PIN_FLD_RUM_MAP array for each RUM. This array includes the minimum quantity for each RUM.
Note:
If you have enabled the Piggyback business parameter to generate in-session notifications, PCM_OP_ACT_REAUTHORIZE and PCM_OP_RESERVE_EXTEND append credit threshold breach information to their responses. For more information on enabling Piggyback, see "Enabling In-Session Notifications".To receive credit threshold breach information when you call PCM_OP_ACT_REAUTHORIZE or PCM_OP_RESERVE_EXTEND directly from testnap or a custom application, set the PIN_FLD_PIGGYBACK_FLAG in the input flist when you call the specific opcode. See "About Setting Up Custom Applications to Receive Credit Threshold Breach Information" for more information .
PCM_OP_RESERVE_EXTEND does one of the following:
For an amount-based request, compares the requested amount against the account's resources. Depending on the results of the comparison, PCM_OP_RESERVE_EXTEND takes one of the actions listed in Table 7-7:
Table 7-7 Actions Taken by PCM_OP_RESERVE_EXTEND
| Comparison Result | PCM_OP_RESERVE_EXTEND Action |
|---|---|
|
Resources are greater than or equal to the requested amount. |
|
|
Resources are less than the requested amount but greater than or equal to the input PIN_FLD_MIN_QUANTITY value. |
|
|
Resources are less than the input PIN_FLD_MIN_QUANTITY value. |
|
For a quantity-based request, calls PCM_OP_ACT_USAGE in CALC_ONLY mode to determine whether the account's resources can cover the requested quantity or quantities. See "How Rating Works" in BRM Setting Up Pricing and Rating for more information.
If the full quantity or quantities cannot be covered, BRM determines the maximum resource amounts that can be reserved. See "Credit Limit Checks during Prepaid Authorization" for more information.
If you enabled in-session notifications, PCM_OP_ACT_USAGE is called with PIN_FLD_PIGGGYBACK_FLAG set to 1 (enabled). PCM_OP_ACT_USAGE calculates the credit threshold breaches and returns any breach information in its output flist. See "How BRM Provides Credit Threshold Breach Notifications" for more information.
Based on the results returned by PCM_OP_ACT_USAGE, PCM_OP_RESERVE_EXTEND takes one of the actions listed in Table 7-8:
Table 7-8 Actions Taken by PCM_OP_RESERVE_EXTEND
| PCM_OP_ACT_USAGE Result | PCM_OP_RESERVE_EXTEND Action |
|---|---|
|
Single-RUM The account's resources cover the requested quantity. Multi-RUM The account's resources cover all requested quantities. |
|
|
Single-RUM The account's resources cover more than the currently reserved quantity but do not cover the full requested quantity. Multi-RUM The account's resources cover more than the currently reserved quantity for all RUMs, but do not cover the full requested quantity for at least one RUM. |
|
|
Single-RUM The available resources cover less than the minimum quantity for the RUM. Multi-RUM The available resources cover less than the minimum quantity for at least one RUM. |
|
|
Single-RUM The requested quantity is less than the minimum for the RUM. Multi-RUM Any requested quantity is less than the minimum quantity for that RUM. |
|
|
Single-RUM No resources available. Multi-RUM No resources available for all RUMs. |
|
For policy-driven charging sessions, the PCM_OP_RESERVE_EXTEND opcode updates the consumed reservation amount for the service in the /reservation and /balance_group objects.
Based on the results passed in from PCM_OP_RESERVE_EXTEND, PCM_OP_ACT_REAUTHORIZE takes one the actions in Table 7-9:
Table 7-9 Actions Taken by PCM_OP_ACT_REAUTHORIZE
| PCM_OP_RESERVE_EXTEND Result | PCM_OP_ACT_REAUTHORIZE Action |
|---|---|
|
PIN_RESERVATION_SUCCESS |
|
|
PIN_RESERVATION_INSUFFICIENT_FUNDS |
|
|
PIN_RESERVATION_NO_FUNDS |
|
|
PIN_RESERVATION_INSUFFICIENT_RATED_QTY |
|
|
PIN_RESERVATION_INVALID_REQUESTED_QTY |
|
If this is the first usage session of a resource whose validity period is based on first usage and the SetFirstUsageInSession business parameter is enabled, PCM_OP_BAL_APPLY_MULTI_BAL_IMPACTS is called to set the start time of the resource's validity period to the start time of the first usage session.
Note:
By default, SetFirstUsageInSession is disabled, and the start time of the validity period is set at the end of the first usage session to the end time of that session. For more information, see "About Setting Resource Validity Periods Based on First Usage" in BRM Setting Up Pricing and Rating.PCM_OP_ACT_REAUTHORIZE calls the PCM_OP_ACT_POL_POST_REAUTHORIZE policy opcode to make any specified customizations to its output flist before returning the flist to the calling opcode. By default, the policy opcode drops the PIN_FLD_RESULTS field from the flist.
At the POST_PROCESS stage, PCM_OP_TCF_AAA_UPDATE_AND_REAUTHORIZE calls the helper opcode specified in the /config/opcodemap/tcf object.
PCM_OP_TCF_AAA_UPDATE_AND_REAUTHORIZE returns to the caller either success or failure.
If the Piggyback business parameter is enabled, PCM_OP_TCF_AAA_UPDATE_AND_REAUTHORIZE calls the PCM_OP_TCF_AAA_POL_POST_PROCESS policy opcode to set up the required in-session notifications. See "How BRM Provides In-Session Notifications" for more information.
For more information about canceling prepaid authorization, see "About Canceling Authorizations for Prepaid Usage".
The main opcode for canceling authorization is PCM_OP_TCF_AAA_CANCEL_AUTHORIZATION.
BRM cancels prepaid authorization as follows:
PCM_OP_TCF_AAA_CANCEL_AUTHORIZATION calls PCM_OP_ACT_FIND to retrieve the customer's account information. The opcode returns the customer's /account and /service objects.
If the service type is not provided in the input flist, the PCM_OP_ACT_FIND opcode finds all the matching service instances of the MSID as the login, depending on whether you use a single-schema, a multischema, or an Oracle IMDB Cache-enabled BRM system.
At the SEARCH_SESSION stage, PCM_OP_TCF_AAA_CANCEL_AUTHORIZATION calls the helper opcode specified in the /config/opcodemap/tcf object. The helper opcode returns a search template for finding the /active_session object.
PCM_OP_TCF_AAA_CANCEL_AUTHORIZATION uses the search template to find the /active_session object to cancel. If the object is not found, the opcode generates an error.
PCM_OP_TCF_AAA_CANCEL_AUTHORIZATION calls PCM_OP_ACT_CANCEL_AUTHORIZE with the /active_session POID, the list of reservations associated with the session, and the optional delete flag.
PCM_OP_ACT_CANCEL_AUTHORIZE calls PCM_OP_RESERVE_RELEASE to release any reserved resources.
PCM_OP_RESERVE_RELEASE calls the PCM_OP_RESERVE_POL_PRE_RELEASE policy opcode to perform custom validation.
PCM_OP_RESERVE_RELEASE updates the customer's reservation and account balances and then either saves or deletes the reservation object, depending on the value of the PIN_FLD_DELETED_FLAG input flist field:
If the flag is set to 1, the opcode deletes the reservation object.
If the flag is set to any other value or is missing, the opcode saves the reservation object.
For policy-driven charging sessions, PCM_OP_RESERVE_RELEASE clears the consumed reservation amount for the service from the /balance_group object.
The opcode returns the /account POID and the list or reservation objects that were released.
PCM_OP_ACT_CANCEL_AUTHORIZE calls the PCM_OP_ASM_CLOSE_ACTIVE_SESSION opcode to cancel the active session.
PCM_OP_ASM_CLOSE_ACTIVE_SESSION determines whether to delete the /active_session object by reading the PIN_FLD_STATUS_FLAG input flist field:
PCM_OP_ASM_CLOSE_ACTIVE_SESSION does the following:
If the PIN_FLD_STATUS_FLAG input flist field is:
1, this opcode deletes the /active_session object.
0, this opcode confirms that the object's status is CREATED or UPDATED, and then updates the object's status to CANCELLED.
Returns the POID of the /active_session object.
PCM_OP_ACT_CANCEL_AUTHORIZE returns to PCM_OP_TCF_AAA_CANCEL_AUTHORIZE the POID of the /active_session object.
PCM_OP_TCF_AAA_CANCEL_AUTHORIZE returns to the caller the /account POID and authorization ID.
The main opcode for rating and recording prepaid activity events is PCM_OP_TCF_AAA_ACCOUNTING.
BRM rates and records prepaid activity events as follows:
PCM_OP_TCF_AAA_ACCOUNTING calls the PCM_OP_ACT_FIND opcode to locate the customer's account information. The opcode returns the customer's /account and /service objects.
If the service type is not provided in the input flist, the PCM_OP_ACT_FIND opcode finds all the matching service instances of the MSID as the login, depending on whether you use a single-schema, a multischema, or an Oracle IMDB Cache-enabled BRM system.
PCM_OP_TCF_AAA_ACCOUNTING opens a master transaction and calls the PCM_OP_BAL_LOCK_RESERVATION_LIST opcode to lock the /reservation_list object.
At the SEARCH_SESSION stage, PCM_OP_TCF_AAA_ACCOUNTING calls the helper opcode specified in the /config/opcodemap/tcf object. The helper opcode returns a search template for finding session objects.
PCM_OP_TCF_AAA_ACCOUNTING uses the search template to look for duplicate session objects. If the opcode finds a session object with a matching authorization ID and a status of Closed or Cancelled, this is a duplicate request and the opcode returns with an error.
Note:
If it is operating in either the aggregate subsession mode or the deferred rate subsession mode, the opcode may find multiple /active_session objects that meet the criteria.At the PREP_INPUT stage, PCM_OP_TCF_AAA_ACCOUNTING calls the helper opcode specified in the /config/opcodemap/tcf object to aggregate service-specific data. The opcode returns a service-specific input flist.
Note:
When operating in either the aggregate subsession mode or the deferred rate subsession mode, the PREP_INPUT opcode returns the PIN_FLD_SESSION_INFO array with all of the subsession /active_session objects and master session information in the top level.At the VALIDATE_LIFECYCLE stage, PCM_OP_TCF_AAA_ACCOUNTING calls the helper opcode specified in the /config/opcodemap/tcf object to validate the request if the service uses a custom life cycle. If validation succeeds, the accounting process continues. If validation fails, the request is denied.
PCM_OP_TCF_AAA_ACCOUNTING passes the service-specific input flist to PCM_OP_ACT_ACTIVITY opcode.
If the session includes a master session and one or more subsessions, PCM_OP_TCF_AAA_ACCOUNTING performs the following:
Calls PCM_OP_ACT_ACTIVITY with information about the master session object. PCM_OP_ACT_ACTIVITY creates the event and calculates the balance impact for the activity.
For each subsession object passed in the PIN_FLD_SESSION_INFO array, calls PCM_OP_ACT_ACTIVITY with information about the subsession. The opcode also passes the /event POID of the master object and sets the subsession's status to one of the following:
Closed, if the subsession mode is deferred rate mode or rate mode.
Closed and unrated, if the subsession mode is aggregate mode.
PCM_OP_TCF_AAA_ACCOUNTING closes the master transaction.
PCM_OP_TCF_AAA_ACCOUNTING returns to the caller the /event POID, the authorization ID, the /account and /service POIDs, and the charge for the activity.
The main opcode for refunding charges for prepaid activity events is PCM_OP_TCF_AAA_REFUND.
BRM refunds charges for prepaid activity events as follows:
PCM_OP_TCF_AAA_REFUND calls the PCM_OP_ACT_FIND opcode to locate the customer's account information. The opcode returns the customer's /account and /service objects.
If the service type is not provided in the input flist, the PCM_OP_ACT_FIND opcode finds all the matching service instances of the MSID as the login, depending on whether you use a single-schema, a multischema, or an Oracle IMDB Cache-enabled BRM system.
At the SEARCH_SESSION stage, PCM_OP_TCF_AAA_REFUND calls the helper opcode specified in the /config/opcodemap/tcf object. The helper opcode returns a search template for finding session objects.
PCM_OP_TCF_AAA_REFUND uses the search template to look for the /event/session/* and /event/activity/* objects.
PCM_OP_TCF_AAA_REFUND checks if the PIN_FLD_ADJUSTMENT_INFO array is present in the input flist.
If the PIN_FLD_ADJUSTMENT_INFO array is present, PCM_OP_TCF_AAA_REFUND calls PCM_OP_AR_EVENT_ADJUSTMENT to perform event adjustment.
If the PIN_FLD_ADJUSTMENT_INFO array is not present, PCM_OP_TCF_AAA_REFUND checks the PIN_FLD_CALL_DURATION field for the unused duration of time (in seconds) to be refunded.
PCM_OP_TCF_AAA_REFUND calls PCM_OP_ACT_USAGE in CALC_ONLY mode to determine the balance impacts.
PCM_OP_TCF_AAA_REFUND uses the balance impacts to prepare PIN_FLD_ADJUSTMENT_INFO.
PCM_OP_TCF_AAA_REFUND calls PCM_OP_AR_EVENT_ADJUSTMENT to perform event adjustment and then closes the master transaction.
PCM_OP_TCF_AAA_REFUND returns the /event/notification/refund event notification.
For more information about managing prepaid sessions, see "About Accounting for Prepaid Sessions".
When a customer is authorized to use a prepaid service, BRM creates an /active_session object to record information about the customer's usage while the session is in progress. For example, the object stores the session's starting time, the associated reservation objects, and the amount the customer has currently consumed. When the session ends, BRM closes the /active_session object, records information about the completed session in an /event/session object, and then sends the session information to the rating process.
BRM tracks the /active_session object's life cycle by using the PIN_FLD_STATUS field. Active sessions can be set to one of the following states: CREATED, STARTED, UPDATED, RATED, or CLOSED.
When the requested quota is greater than the available amount, BRM readjusts the quota and sends that information to the network connectivity application (if the piggyback business parameter is enabled). See "Providing In-Session Notifications for Network Connectivity Applications" for more information.
For policy-driven sessions, BRM evaluates the requested quota in the incoming requests based on the configuration in the offer profile and the account details.
If BRM detects a breach of the policy threshold in the offer profile during the quota readjustment, it sends a threshold breach notification to the network policy controller. Such threshold breach notifications are sent for in-session and out-of-session occurrences of the threshold breach.
See "Policy-Driven Charging" in BRM Setting Up Pricing and Rating.
The main opcode for starting prepaid sessions is PCM_OP_TCF_AAA_START_ACCOUNTING. You use this opcode to record the session's starting time.
BRM starts a prepaid session as follows:
PCM_OP_TCF_AAA_START_ACCOUNTING calls the PCM_OP_ACT_FIND opcode to locate the customer's account information. The opcode returns the customer's /account and /service objects.
If the service type is not provided in the input flist, the PCM_OP_ACT_FIND opcode finds all the matching service instances of the MSID as the login, depending on whether you use a single-schema, a multischema, or an Oracle IMDB Cache-enabled BRM system.
At the SEARCH_SESSION stage, PCM_OP_TCF_AAA_START_ACCOUNTING calls the helper opcode specified in the /config/opcodemap/tcf object. The helper opcode returns a search template for finding the /active_session object.
PCM_OP_TCF_AAA_START_ACCOUNTING uses the search template to find the /active_session object to update.
At the PREP_INPUT stage, PCM_OP_TCF_AAA_START_ACCOUNTING calls the helper opcode specified in the /config/opcodemap/tcf object to aggregate service-specific data. The opcode returns a service-specific input flist.
PCM_OP_TCF_AAA_START_ACCOUNTING calls the PCM_OP_ACT_START_SESSION opcode with the input flist to start the prepaid session.
PCM_OP_ACT_START_SESSION either updates or creates the /active_session object, depending on the value of the PIN_FLD_POID input flist field:
If the field contains a complete POID, the opcode calls the PCM_OP_ASM_UPDATE_ACTIVE_SESSION opcode to update the /active_session object and change its status from Created to Started.
If the field contains a POID type only, the opcode calls the PCM_OP_ASM_CREATE_ACTIVE_SESSION opcode to create the /active_session object, record the session start time, and set the object's status to Created.
PCM_OP_ACT_START_SESSION returns to PCM_OP_TCF_AAA_START_ACCOUNTING the POID of the /active_session object.
PCM_OP_TCF_AAA_START_ACCOUNTING returns to the caller the /active_session POID, /account POID, /service POID, and authorization ID.
The main opcode for updating prepaid sessions is PCM_OP_TCF_AAA_UPDATE_ACCOUNTING. You use this opcode to find and update an existing /active_session object or, if one does not already exist, create an /active_session object.
BRM updates a prepaid session as follows:
PCM_OP_TCF_AAA_UPDATE_ACCOUNTING calls the PCM_OP_ACT_FIND opcode to locate the customer's account information. The opcode returns the customer's /account and /service objects.
If the service type is not provided in the input flist, the PCM_OP_ACT_FIND opcode finds all the matching service instances of the MSID as the login, depending on whether you use a single-schema, a multischema, or an Oracle IMDB Cache-enabled BRM system.
At the SEARCH_SESSION stage, PCM_OP_TCF_AAA_UPDATE_ACCOUNTING calls the helper opcode specified in the /config/opcodemap/tcf object. The helper opcode returns a search template for finding session objects.
PCM_OP_TCF_AAA_UPDATE_ACCOUNTING uses the template to search for the /active_session object.
At the PREP_INPUT stage, PCM_OP_TCF_AAA_UPDATE_ACCOUNTING calls the helper opcode specified in the /config/opcodemap/tcf object to aggregate service-specific data. The opcode returns a service-specific input flist.
PCM_OP_TCF_AAA_UPDATE_ACCOUNTING passes the data from the helper opcode to the PCM_OP_ACT_UPDATE_SESSION opcode.
PCM_OP_ACT_UPDATE_SESSION determines whether to update or create the /active_session object by checking the PIN_FLD_POID input flist field.
If the field contains a complete POID, the opcode calls the PCM_OP_ASM_UPDATE_ACTIVE_SESSION opcode to update the /active_session object's data and status. The opcode returns the POID of the updated /active_session object.
If the field contains a POID type only, the opcode calls the PCM_OP_ASM_CREATE_ACTIVE_SESSION opcode to create the /active_session object. The opcode returns the POID of the created /active_session object.
PCM_OP_TCF_AAA_UPDATE_ACCOUNTING returns to the caller the /active_session POID, /account POID, /service POID, authorization ID, and current session balance.
The main opcode for ending prepaid sessions is PCM_OP_TCF_AAA_STOP_ACCOUNTING. When a session ends, BRM performs the following tasks:
Closes or deletes the /active_session object.
Releases all reservations associated with the session.
Rates the customer's usage.
By default, if this is the first usage session, sets the validity start time to the end time of the session for validity periods based on first usage.
Note:
The default behavior occurs when the SetFirstUsageInSession business parameter is disabled.If SetFirstUsageInSession is enabled, the validity start time is set to the start time of the first usage session when BRM authorizes or updates and reauthorizes that session.
See "About Setting Resource Validity Periods Based on First Usage" in BRM Setting Up Pricing and Rating.
Debits the customer's prepaid account balance.
Stores information about the completed session in an /event/session object in the BRM database.
Sends notification of any threshold breach to the network connectivity application.
BRM ends prepaid sessions as follows:
PCM_OP_TCF_AAA_STOP_ACCOUNTING calls PCM_OP_ACT_FIND to locate the customer's account information. The opcode returns the customer's /account and /service objects.
If the service type is not provided in the input flist, the PCM_OP_ACT_FIND opcode finds all the matching service instances of the MSID as the login, depending on whether you use a single-schema, a multischema, or an Oracle IMDB Cache-enabled BRM system.
PCM_OP_TCF_AAA_STOP_ACCOUNTING opens a master transaction and calls the PCM_OP_BAL_LOCK_RESERVATION_LIST opcode to lock the /reservation_list object.
At the SEARCH_SESSION stage, PCM_OP_TCF_AAA_STOP_ACCOUNTING calls the helper opcode specified in the /config/opcodemap/tcf object. The helper opcode returns a search template for finding session objects.
PCM_OP_TCF_AAA_STOP_ACCOUNTING uses the search template to look for duplicate session objects. If the opcode finds a session object with a matching authorization ID and a status of Closed or Cancelled, this is a duplicate request and the opcode returns with an error.
Note:
If it is operating in either the aggregate subsession mode or the deferred rate subsession mode, the opcode may find multiple /active_session objects that meet the criteria.If an /active_session object is not found, PCM_OP_TCF_AAA_STOP_ACCOUNTING calls the PCM_OP_ASM_CREATE_ACTIVE_SESSION opcode to create an /active_session object with the information from the input flist.
At the PREP_INPUT stage, PCM_OP_TCF_AAA_STOP_ACCOUNTING calls the helper opcode specified in the /config/opcodemap/tcf object to aggregate service-specific data. The opcode returns a service-specific input flist.
Note:
When operating in either the aggregate subsession mode or the deferred rate subsession mode, the PREP_INPUT opcode returns the PIN_FLD_SESSION_INFO array and the master session data in the top level of the flist.(Direct debit mode Only) At the VALIDATE_LIFECYCLE stage, PCM_OP_TCF_AAA_STOP_ACCOUNTING calls the helper opcode specified in the /config/opcodemap/tcf object to validate the request if the service uses a custom life cycle. If validation succeeds, the stop accounting process continues. If validation fails, the request is denied.
PCM_OP_TCF_AAA_STOP_ACCOUNTING passes the service-specific flist to the PCM_OP_ACT_END_SESSION opcode with information about the session.
If the session includes a master session and one or more subsessions, PCM_OP_TCF_AAA_ACCOUNTING performs the following, depending on the subsession mode:
In aggregate mode, the opcode cleans up all of the subsessions and then calls the PCM_OP_ACT_END_SESSION opcode to rate and record the event for the master session.
In deferred rate mode, the opcode rates the master session first by calling PCM_OP_ACT_END_SESSION and retrieving the event POID. Then, the opcode rates all of the subsessions by calling the PCM_OP_ACT_END_SESSION opcode and passing the master session POID.
In rate mode, the opcode calls PCM_OP_ACT_END_SESSION to rate and record the session.
PCM_OP_TCF_AAA_ACCOUNTING confirms that the master session and all subsessions have ended and have been processed.
Note:
You can configure the opcode to skip this step by using the Services Framework AAA pin.conf file. For more information, see "Ensuring That All Subsessions Have Stopped before Closing the Master Session".PCM_OP_TCF_AAA_ACCOUNTING closes the master session and subsessions:
In aggregation mode, the opcode sets the master session to Closed and all subsessions to Closed and Unrated.
In deferred rate mode, the opcode sets the master session and all subsessions to Closed.
In rate mode, the opcode sets the master session and all subsessions to Closed.
PCM_OP_TCF_AAA_STOP_ACCOUNTING returns to the caller the /event/session POID, the /account POID, the /service POID, and the rated amount to the calling application.
If the Piggyback business parameter is enabled, PCM_OP_TCF_AAA_STOP_ACCOUNTING calls the PCM_OP_TCF_AAA_POL_POST_PROCESS policy opcode to set up the required in-session notifications. See "How BRM Provides In-Session Notifications" for more information.
The main opcode for closing active sessions when the external network shuts down is PCM_OP_TCF_AAA_ACCOUNTING_OFF. You can control whether BRM rates newly created active sessions before closing them by using the PIN_FLD_ACC_FLAG input flist field.
BRM closes sessions when the network shuts down as follows:
At the ACC_ON_OFF_SEARCH stage, PCM_OP_TCF_AAA_ACCOUNTING_OFF calls the helper opcode specified in the /config/opcodemap/tcf object. The helper opcode returns a search template for finding /active_session objects.
PCM_OP_TCF_AAA_ACCOUNTING_OFF uses the search template to find all session objects that meet the criteria.
PCM_OP_TCF_AAA_ACCOUNTING_OFF performs one of the following for each session object, depending on the object's status:
If the object's PIN_FLD_STATUS field is set to CREATED and the PIN_FLD_ACC_FLAG input flist field is set to TRUE, calls the PCM_OP_TCF_AAA_STOP_ACCOUNTING opcode to end the session and rate any usage.
If the object's PIN_FLD_STATUS field is set to CREATED and the PIN_FLD_ACC_FLAG input flist field is set to FALSE, calls the PCM_OP_TCF_AAA_CANCEL_AUTHORIZATION opcode to cancel the authorization.
If the object's PIN_FLD_STATUS field is set to STARTED or UPDATED, calls PCM_OP_TCF_AAA_STOP_ACCOUNTING to end the session and rate any usage.
PCM_OP_TCF_AAA_ACCOUNTING_OFF returns the POID of each closed object.
The main opcode for closing active sessions when the external network restarts is PCM_OP_TCF_AAA_ACCOUNTING_ON.
You can control whether BRM rates newly created active sessions before closing them by using the PIN_FLD_ACC_FLAG input flist field.
BRM closes sessions when the network shuts down as follows:
At the ACC_ON_OFF_SEARCH stage, PCM_OP_TCF_AAA_ACCOUNTING_ON calls the helper opcode specified in the /config/opcodemap/tcf object. The helper opcode returns a search template for finding /active_session objects.
PCM_OP_TCF_AAA_ACCOUNTING_ON uses the search template to find all session objects that meet the criteria.
PCM_OP_TCF_AAA_ACCOUNTING_ON performs one of the following for each session object, depending on the object's status:
If the object's PIN_FLD_STATUS field is set to CREATED and the PIN_FLD_ACC_FLAG input flist field is set to TRUE, calls the PCM_OP_TCF_AAA_STOP_ACCOUNTING opcode to end the session and rate any usage.
If the object's PIN_FLD_STATUS field is set to CREATED and the PIN_FLD_ACC_FLAG input flist field is set to FALSE, calls the PCM_OP_TCF_AAA_CANCEL_AUTHORIZATION opcode to cancel the authorization.
If the object's PIN_FLD_STATUS field is set to STARTED or UPDATED, calls PCM_OP_TCF_AAA_STOP_ACCOUNTING to end the session and rate any usage.
PCM_OP_TCF_AAA_ACCOUNTING_ON returns the POID of each closed object.
You use the PCM_OP_ACT_POL_SCALE_MULTI_RUM_QUANTITIES policy opcode to scale multi-RUM quantities for prepaid authorization and reauthorization requests. This opcode is called by the PCM_OP_TCF_AAA_AUTHORIZE opcode or the PCM_OP_TCF_AAA_REAUTHORIZE opcode during prepaid authorization and reauthorization for multi-RUM quantities.
For initial authorization requests, the PCM_OP_ACT_POL_SCALE_MULTI_RUM_QUANTITIES opcode scales quantities based on ratios that you specify in the /config/reserve object for the appropriate service. See "Specifying Default Authorization and Reauthorization Values" for more information.
For reauthorization, the opcode can use the actual usage for the session to determine the ratio of the RUMs to be reauthorized. If its input flist includes information about used quantities for each RUM, the opcode automatically calculates the scaling ratio based on the usage. If usage information is not included in the input flist, the opcode continues to use the configured ratio.
Scaling is based on the relationship of each RUM to the primary RUM. The opcode identifies the primary RUM by the presence of the PIN_FLD_IS_PRIMARY_RUM field in the PIN_FLD_QUANTITIES array for the RUM. There can be only one primary RUM in a request.
The formula used for scaling each non-primary RUM is:
Net quantity = Requested quantity of primary RUM * Ratio (static or dynamic)
where:
The static ratio is the ratio configured in the /config/reserve object.
The dynamic ratio is calculated for each RUM based on usage information:
Ratio = Quantity used for the RUM/Quantity used of primary RUM
You can modify this policy opcode to implement customized scaling behavior. For example, you can change the default formulas used for scaling.
When BRM authorizes prepaid usage, it performs a credit limit check to determine whether the customer has sufficient resources available to authorize the requested quantity. See "About Determining whether there Are Sufficient Resources" for an overview.
The credit limit check takes place in one of two possible locations:
If the event is rated by a single RUM and is not eligible for discounts or charge sharing, the credit check is performed by rating opcodes during real-time rating. See "About Credit Limit Checks by Rating Opcodes" for more information.
If an event is rated by multiple RUMs or is eligible for discounts or charge sharing, the credit limit check is performed by the FCT_CreditLimitCheck module in the real-time discounting pipeline. See "About Credit Limit Checks in the Real-Time Discounting Pipeline" for more information.
For events that are rated by a single RUM and are not eligible for discounts or charge sharing, credit limit checks are performed by the PCM_OP_RATE_EVENT opcode in CALC_ONLY mode during real-time rating. When the opcode rates the event in CALC_ONLY mode, it compares the rated amount against the customer's current prepaid balance, less any active reservations. If the customer's available resources are greater than the rated amount, the requested quantity is authorized and resources are reserved. See "How Rating Works" in BRM Setting Up Pricing and Rating.
If the customer's resources cannot allocate the entire requested quantity, PCM_OP_RATE_EVENT reserves the quantity that can be authorized and returns the quantity that cannot be reserved as unrated quantity.
BRM performs credit limit checks in the real-time discounting pipeline under the following circumstances:
The event being authorized is rated by multiple RUMs. For example, an authorization for downloading data could be rated by both duration and volume. In this case, the user's resources must be sufficient for both RUMs.
The event being authorized is eligible for discounts, including discount sharing, charge sharing, free minutes, loyalty points, and so on. Discounts need to be applied prior to checking the credit limit.
In either of these situations, real-time rating rates the event but does not perform a credit check. It sets the CREDIT_LIMIT_CHECK_FLAG and passes information about the event to the real-time discounting pipeline, which performs the credit check by using the FCT_CreditLimitCheck module. See BRM Configuring Pipeline Rating and Discounting for more information.
FCT_CreditLimitCheck performs its credit limit check in two stages:
In the first stage, this module estimates the cost of usage, factoring in all discount and charge sharing amounts, and compares it against the customer's available resources. If more than one RUM applies, the estimate includes all RUMs. If the check fails, the module moves to the second stage. If the check passes, the module skips the second stage.
If the first stage of the credit limit check fails, the module determines the maximum quantity or quantities that can be authorized given the customer's resources. The module determines the maximum authorized quantities for single-RUM with discounts and multiple-RUM scenarios. See "Calculating Maximum Quantities for Single-RUM Authorization Requests with Discounts" and "Calculating Maximum Quantities for Multi-RUM Authorization Requests" for more information.
FCT_CreditLimitCheck performs credit limit checks as follows:
Determines whether to perform credit limit checking by reading the DETAIL.CREDIT_LIMIT_CHECK field in the event data record (EDR.)
If CREDIT_LIMIT_CHECK is set to 1, the module proceeds to the next step.
If CREDIT_LIMIT_CHECK is set to 0, the module skips the credit limit check and sets the DETAIL.CREDIT_LIMIT_CHECK_RESULT field to 1.
Performs a simple credit limit check by comparing the net impact on each resource in each balance group to the balances. See "Determining Whether there Are Sufficient Resources" for more information.
If resources are sufficient to authorize, the module sets the DETAIL.CREDIT_LIMIT_CHECK_RESULT field to 1 and sets the DETAIL.UNRATED_QUANTITY field to 0.
If any balances are insufficient, the module proceeds to the next step.
Determines the maximum quantity or quantities that can be authorized. See "Calculating Maximum Quantities for Single-RUM Authorization Requests with Discounts" and "Calculating Maximum Quantities for Multi-RUM Authorization Requests" for more information.
Sets the DETAIL.CREDIT_LIMIT_CHECK_RESULT field to 0 and adds information about quantities and resources to the EDR.
For multi-RUM requests, separate charge and discount packets are created for each RUM. The DETAIL.ASS_CBD.RM.UNRATED_QUANTITY field is set to the quantity that cannot be rated for each RUM.
The data from the EDR is passed back to the reservation opcodes, which reserve the appropriate resources.
When an authorization request is made, FCT_CreditLimitCheck determines whether there are sufficient resources to authorize the requested quantity by comparing the balance impact of all the charge packets for each RUM with the balance of each resource.
The charge packets are created by the FCT_Discount module based on the QUANTITY_FROM and QUANTITY_TO values in the charge and discount packets. FCT_Discount breaks the requested quantity into linear segments such that each charge packet has a single net rate, after applying the discounts and charge shares.
For example, if rate R1 applies for the first 50 minutes, rate R2 applies for all subsequent usage, and discount D1 applies for the first 25 minutes, there would be three segments for a 100-minute authorization, as shown in Table 7-10:
Table 7-10 Calculating Usage by Rates
| Segment | Rate | Discount | Net Rate |
|---|---|---|---|
|
0 – 25 |
R1 |
D1 |
R1 - D1 |
|
25 – 50 |
R1 |
none |
R1 |
|
50 – 100 |
R2 |
none |
R2 |
Using the segment information added to the EDR by FCT_Discount, FCT_CreditLimitCheck:
Sequentially checks each charge packet to determine whether the customer has enough resources to allocate for the net impact of the charge after the discount for that segment. The resources that can be reserved are added to the quantity to be authorized.
When it reaches a charge packet that cannot be authorized fully by the customer's resources, calculates the portion of the charge packet that can be authorized. This prorated quantity is added to the quantity to be authorized.
Sums the quantities for each packet and returns that total quantity for authorization.
The following example shows how credit limit check is performed for non-currency resource balances.
Suppose that a customer wants to use a service that costs $1.00 per minute. The customer's current prepaid balance is $20 and 10 free minutes resource balance. The customer is eligible for 10% discount on the first 10 minutes and 20% discount after that. The authorization request is for 30 minutes.
FCT_Discount breaks the requested quantity into three segments, as shown in Table 7-11:
Table 7-11 Request Segmentation by FCT_Discount
| Time | Rate | Discount | Net Rate |
|---|---|---|---|
|
0 – 10 |
$1.00/min. |
–100% |
$0/min. |
|
10 – 20 |
$1.00/min. |
–10% |
$0.90/min. |
|
20 – 30 |
$1.00/min. |
–20% |
$0.80/min. |
Using the segment information, FCT_CreditLimitCheck:
Sequentially checks each charge packet to determine whether the customer's resource balance can authorize it.
The first charge packet (10 minutes) is $0. It consumes from the free resource buckets first, leaving 0 free minutes and $20 prepaid balance.
The second charge packet (10 minutes) is $9, leaving a $11 prepaid balance.
The third charge packet (10 minutes) is $8, leaving a $3 prepaid balance.
Sums the quantities for each charge packet and returns that total quantity for authorization. The total quantity authorized is 30 minutes at a cost of $17.00.
The following example shows how credit limit check is performed for currency resource balances.
Suppose that a customer wants to use a service that costs $5.00 per minute. The customer's current prepaid balance is $30 and a free monetary credit of $20. The customer is eligible for a 10% discount on the first $10 charge and a 20% discount on all charges after that. The authorization request is for 10 minutes.
FCT_Discount converts the equivalent charge to the equivalent call duration and breaks the requested quantity into three segments, as shown in Table 7-12:
Table 7-12 Request Segmentation for Equivalent Charges by FCT_Discount
| Time | Rate | Discount | Net Rate |
|---|---|---|---|
|
0 – 4 |
$5.00/min. |
–100% |
$0.00/min. |
|
4 – 6 |
$5.00/min. |
–10% |
$4.50/min. |
|
6 – 10 |
$5.00/min. |
–20% |
$4.00/min. |
Using the segment information, FCT_CreditLimitCheck:
Sequentially checks each charge packet to determine whether the customer has resources to authorize it.
The first charge packet (4 minutes) is $0. It consumes from the free resource buckets first, leaving a $0 free monetary credit balance and $30 prepaid balance.
The second charge packet (2 minutes) is $9, leaving a $21 prepaid balance.
The third charge packet (4 minutes) is $16, leaving a $5 prepaid balance.
Sums the quantities for each segment and returns that total quantity for authorization. The total quantity authorized is 10 minutes at a cost of $25.00.
When an initial credit limit check fails for a single-RUM authorization request, FCT_CreditLimitCheck determines the maximum quantity that can be authorized by sequentially checking segments of the request.
Suppose that a customer wants to use a service that costs $1.00 per minute for the first 40 minutes and $0.50 per minute after that. The customer is eligible for a 20% discount on the first 10 minutes and a 40% discount after that. The customer's current balance is $38 and the authorization request is for 100 minutes.
FCT_Discount breaks the requested quantity into multiple charge and discount packets based on the rates and discounts that apply. Table 7-13 shows the three segments:
Table 7-13 Request Segmentation by FCT_Discount
| Time | Rate | Discount | Net Rate |
|---|---|---|---|
|
0 – 10 |
$1.00/min. |
–20% |
$0.80/min. |
|
10 – 40 |
$1.00/min. |
–40% |
$0.60/min. |
|
40 – 100 |
$0.50/min. |
–40% |
$0.30/min. |
The initial check in FCT_CreditLimitCheck fails because the cost for 100 minutes ($44) is greater than the customer's resources ($38). The module then does the following to determine the maximum quantity that can be authorized for the session:
Sequentially checks each segment to determine whether the customer has resources to authorize it.
The first segment costs less than the balance of $38. Its 10 minutes can be authorized at a cost of $8, leaving a $30 balance.
The second segment costs less than the remaining balance of $30. Its 30 minutes can be authorized at a cost of $18, leaving a $12 balance.
The third segment costs more than the remaining balance of $12, so the segment must be prorated. The net cost per minute is $0.30, so 40 minutes can be authorized for the remaining balance of $12.
Sums the quantities for each segment and returns that total quantity for authorization. The total that can be authorized is 80 minutes at a cost of $38.00.
If an initial credit limit check fails for a multi-RUM authorization request, FCT_CreditLimitCheck determines the maximum quantity that can be authorized by checking incrementally smaller or larger quantities until the maximums are reached. The maximum is based on the total charge of the charge packets of all RUMs.
The module uses a method similar to a binary search to determine the size of each increment to check, stopping when the increment becomes smaller than the step size for one of the resources.
Note:
Currently, the step size is always 1.To find the maximum quantities of each resource, FCT_CreditLimitCheck:
Divides the originally requested quantities in half.
Compares the cost of the new quantities to the customer's balance, then does one of the following:
If the cost is lower than the customer's balance, increases the requested quantities. Each quantity is increased by half of the difference between it and the originally requested quantity.
If the cost is greater than the customer's balance, decreases the requested quantities. Each quantity is reduced by half of the difference between it and zero.
If the cost of the new quantities is a match for the customer's balance, returns those quantities for authorization.
Compares the combined cost of the quantities determined in the previous step to the customer's balance, then does one of the following:
If the cost is lower than the customer's balance, increases the requested quantities. Each quantity is increased by half of the difference between it and the original quantity or the previously requested quantity, whichever is smaller.
If the cost is greater than the customer's balance, decreases the requested quantities. Each quantity is reduced by half of the difference between the current value and zero or the previously requested quantity, whichever is greater.
If the cost of the new quantities is a match for the customer's balance, returns those quantities for authorization.
Repeats step 3 until dividing the remaining quantities in half results in an increment that is smaller than the step size for at least one resource.
Returns the last successfully checked quantities for authorization.
For example, suppose that a customer requests authorization for a GPRS session with a 20-minute duration and 40 megabytes of data. Minutes are charged at $0.40 per minute and data is charged at $0.50 per megabyte. The customer has a $20 balance.
The initial credit limit check fails because the session cost ($28) is greater than the customer's balance ($20).
FCT_CreditLimitCheck then does the following to determine the maximum quantities that can be authorized for the session:
Divides the initially requested quantities for each RUM in half and checks them as shown in Table 7-14.
The total cost ($14) is less than the customer's balance ($20), so the module increases the quantity of each resource by half of the amount between it and the original quantity, then checks the resulting quantities as shown in Table 7-15.
The total cost ($21) is greater than the customer's balance, so the module reduces the quantity of each RUM by the half the difference between the first and second attempts, then checks the resulting quantities as shown in Table 7-16.
The total cost ($17.50) is less than the customer's balance, so the module increases the quantity of each RUM by half the difference between the second and third attempts, then checks the resulting quantities as shown in Table 7-17.
The cost ($19.25) is less than the customer's balance, but the module cannot try a larger quantity because the minimum step size for minutes is 1. If rounding is enabled, the module returns 14 minutes and 28 megabytes for authorization. If rounding is not enabled, the module returns 13.75 minutes and 27.5 megabytes for authorization. See "Enabling Rounding for Maximum Quantity Results" for more information.
You can choose to have FCT_CreditLimitCheck round up the results of its maximum quantity calculations to the nearest whole number. For example, if the module calculates a maximum quantity of 74.4, rounding would change the quantity to 75.
Note:
Rounded quantities may exceed the customer's available resources by a small amount. The customer will not be charged for the fraction used to round up the quantity.Rounding is disabled by default. You enable rounding by setting RoundUpRequestQuantity to True in the module's registry entry. See "FCT_CreditLimitCheck" in BRM Configuring Pipeline Rating and Discounting for more information.
Note:
Windows users: To display decimals to the desired precision, ensure that your regional settings are properly defined.Because of the way that BRM calculates maximum authorizations, keep the following cases in mind:
Depending on the discount configuration, authorizations for sessions that involve threshold discounts can be incorrect. This occurs because the discount threshold may be triggered by the initial quantity that BRM tries, but not by the quantity actually authorized. BRM cannot know in advance what the actual authorized quantity will be, so it cannot be sure whether the threshold discount applies.
For example, assume that a service is charged at $1.00 minute and is eligible for a threshold discount of $0.50 for calls over 50 minutes. If the threshold value is reached, the discount applies to the entire session.
Suppose the customer's balance is $20. The network attempts an authorization of 100 minutes. Because of its length, the session is eligible for the discount of $0.50 per minute, but the cost ($50) is greater than the customer's balance ($20). As a result, the initial credit limit check by FCT_CreditLimitCheck fails.
The module then calculates the maximum quantity that can be authorized. It bases the calculation on the net cost after the discount, which yields an authorization of 40 minutes.
However, the 40 minutes do not qualify for the $0.50-per-minute discount because it is below the 50-minute threshold. When the call is actually rated, the non-discounted rate applies. This results in a charge of $40, which is larger than the customer's balance.
Sponsor-Limited Authorizations
When an authorization request includes charge sharing, the charge sharing sponsor's balance is factored into credit limit checks. As a result, the sponsor's balance rather than the customer's balance may be the factor that determines the maximum quantity that can be authorized.
For example, assume a customer has a service that is charged at $1.00 per minute and is eligible for a charge share of 40%. If the customer has a balance of $66 and the sponsor a balance of $32, an authorization request for 100 minutes will fail. The customer's balance is more than the amount required to authorize 60% of the charge, but the sponsor's balance of $32 cannot authorize 40% of $100.
FCT_CreditLimitCheck then calculates the maximum quantity that can be authorized. That maximum is reached when either the customer's or the sponsor's balance is reached. In this case, the sponsor's balance is the limiting factor:
For the customer, the net rate is $0.60 per minute. The maximum that could be authorized for the customer's $66 balance is 110 minutes, more than the requested quantity.
For the sponsor, the net rate is $0.40 per minute. The maximum that can be authorized for the sponsor's balance of $32 is 80 minutes.
FCT_CreditLimitCheck would return 80 minutes to be authorized. The sponsor's total balance of $32 would be reserved as well as $48 of the customer's balance.
Discounts that are based on conditions, such as monthly usage totals, cannot be reliably authorized. This occurs because there is no way to guarantee in advance that the condition will be met.
For example, suppose that a customer is eligible for a discount starting when his monthly usage total reaches a certain level. If the authorization request includes enough usage to exceed the specified level, the customer will be authorized for a larger total than would be possible without the discount. However, when the customer's actual usage is rated, it may not be sufficient to trigger the discount condition. In this case, the customer's actual usage may exceed what can be authorized by his available resources.
During prepaid usage authorization, when BRM receives a request to authorize or to update and reauthorize the quota for a session, it readjusts the requested quota based on the current balance, used reservation across all the parallel sessions, and the nearest threshold configured in the offer profile.
At the PREP_INPUT stage of the AAA flow, if /config/reserve object contains a resource id, BRM performs the following operations:
Obtain the balances for all the resources by calling the PCM_OP_BAL_GET_PREPAID_BALANCES opcode.
Retrieve all the offer profiles associated with the service POID and account POID by calling the PCM_OP_OFFER_PROFILE_GET_OFFER_PROFILE opcode.
Calculate the consumed quota. It reduces the consumed quota obtained from the active session object by the CONSUMED_RESERVED _AMOUNT in the BALANCES array for the reservation.
Check if any threshold is crossed by calling the PCM_OP_OFFER_PROFILE_CHECK_POLICY_THRESHOLD opcode and passing offer profiles, service object, resource id, and the updated consumed quota calculated above.
See "About the PCM_OP_OFFER_PROFILE_CHECK_POLICY_THRESHOLD Opcode" in BRM Setting Up Pricing and Rating for more information.
If the requested quota exceeds the available amount, authorize the request for just the available amount.
For example, you configure an offer profile for a non-currency resource such as Megabytes (MB) Used with specific thresholds (at 140MB, 160 MB, and so on).
The current balance on an account for this resource is 80 MB and the consumed reserved amount (across parallel sessions, iPhone, video, and computer) is 35 MB.
The first threshold in the offer profile is 140 MB making the allowable reservation quota 25 MB (140-115).
When BRM receives a request to authorize for that resource and the requested amount exceeds 25 MB, BRM sets the allowable reservation quota for the session at 25 MB.
The session is initiated.
BRM receives an update and reauthorize request. The consumed quota input in that request is 25 MB.
The consumed amount is 140 MB (80 + 35 + 25). The next threshold in the offer profile is 160. This means that the allowable quota is 20 MB.
BRM calculates the consumed amount as 140 MB (80 + 35 + 25). BRM uses the next threshold in the offer profile and calculates 20 MB as the allowable quota (160-140).
If the update and authorize request is for an amount greater than 20 MB, BRM readjusts the allowance to 20 MB.
For more information on:
Authorizing a request, see "How BRM Starts Prepaid Sessions".
Updating and Reauthorizing a request, see "How BRM Updates Prepaid Sessions".
Policy-Driven charging, see "Policy-Driven Charging" in BRM Setting Up Pricing and Rating.