This chapter provides an overview of how your Oracle Communications Billing and Revenue Management (BRM) system performs authentication, authorization, and accounting (AAA) for prepaid services.
Before reading this chapter, you should be familiar with BRM concepts and architecture. See BRM Concepts.
In prepaid environments, an external network and the BRM rating and billing system work together to establish voice and data connections in real time.
The external network collects information about the customer, connects the service, and collects data about the prepaid session while it is in progress.
BRM performs the following functions:
Authenticates customers by verifying their identity. See "About Authenticating Prepaid Customers".
Authorizes customers to use a specific service. See "About Authorizing Prepaid Usage".
Reauthorizes customers for extended usage, if needed. See "About Reauthorizing Prepaid Usage".
Cancels authorization for failed connections. See "About Canceling Authorizations for Prepaid Usage".
Accounts for the results of prepaid sessions in progress. See "About Accounting for Prepaid Sessions".
If your system is configured to receive in-session notifications from BRM (that is, when the piggyback business parameter is enabled), appends specific in-session notifications to the responses it provides for authorization and reauthorization requests sent by a supported network connectivity application. See "Providing In-Session Notifications for Network Connectivity Applications".
If your system is configured for policy-driven charging sessions, sends notifications to the network policy controller when the sum of the current balance and consumed reservation for a given service and resource ID matches the nearest threshold configured in the offer profile for that service and resource ID. (It supports such notifications for both in-session and out-of-session notifications). See "Policy-Driven Charging" in BRM Setting Up Pricing and Rating.
When customers attempt to use a prepaid service, the external network collects information about the customer and sends authentication and authorization requests to BRM. BRM processes the requests and returns the results immediately, so the network can connect the call.
After the service is connected, the external network begins collecting information about the customer's usage and sends the data to BRM, which records the data and rates the usage.
BRM authenticates customers by comparing the ID that the customer provides with the ID stored in the BRM database. The type of ID BRM uses for verification depends on the service type:
For telco services, such as GSM, the ID is typically a device ID, such as an MSID.
For Internet Protocol (IP) services, such as email and Internet access, the ID is typically a login name and password.
BRM authenticates IDs in Password Authentication Protocol (PAP) mode or Challenge-Handshake Authentication Protocol (CHAP) mode.
BRM can perform additional verification checks before approving or denying an authentication request. For example, you can customize BRM to perform these authentication checks:
Credit limit checking. BRM determines whether the customer's account balance currently exceeds the specified limit.
Service status checking. BRM confirms that the requested service is currently active in the customer's account.
Duplicate session checking. BRM checks for duplicate sessions.
For detailed information, see "How BRM Authenticates Prepaid Customers".
BRM uses authorization to ensure that a customer is allowed to access a service, such as GSM telephony or SMS text messaging. Authorization is based on account information, such as the products a customer owns, the services a customer subscribes to, and the customer's current account balance.
BRM authorizes a customer to use a service for:
A specified duration or volume. See "About the Authorized Duration or Volume".
(Volume-based authorizations only) A specified validity period. See "About the Validity Period for Volume-Based Authorizations".
The authorization process includes these operations:
Verifying that the customer has a subscription for the requested product or service.
Determining whether the user has sufficient resources for the requested service or product. See "About Determining whether there Are Sufficient Resources".
Calculating maximum authorizations if a request cannot be fully authorized. For policy-driven charging sessions, readjusting the quota accordingly. See "About Calculating Maximum Authorizations".
Reserving a portion of the customer's resources for the prepaid session. See "About Reserving Resources for Prepaid Services".
If your system is configured to receive in-session notifications from BRM (that is, when the piggyback business parameter is enabled), in-session notifications are appended to the responses returned the network connectivity application. See "Providing In-Session Notifications for Network Connectivity Applications".
For detailed information, see "How BRM Authorizes Users to Access Prepaid Services".
Note:
If you use prepaid lightweight authorization, you can authorize customers who maintain a certain level of resources without requiring BRM to make calls to the rating and discounting engines. You can also reauthorize customers without going through the rating process as long as they maintain the level of resources you specify. See "Using Lightweight Authorization".Customers are authorized to use a service for a specified volume or duration. For example, customers can be authorized to download 100 bytes of data or make a 30-minute telephone call. The volume or duration that customers are initially authorized to use is specified in the authorization request from the network or based on configured default values.
To pass in the authorization volume or duration to the BRM API, see "Authorizing Prepaid Services".
To set default authorization values in BRM, see "Specifying Default Authorization and Reauthorization Values".
For prepaid sessions that are measured by more than one ratable usage metric (RUM), customers are authorized for all applicable resources. For example, a GPRS user might be authorized to use 10 free Anytime minutes and 25 megabytes for a session.
When rates are based on the time of day (TOD), BRM assigns a validity period to all volume-based authorizations. BRM sets the validity period to expire when the rates change. For example, if a customer accesses a service at 10:50 p.m. and the rates change at 11:00 p.m., the validity period is set to 9 minutes 59 seconds. At the end of the validity period, BRM forces a reauthorization at the new rate. This ensures that the authorization is valid for the current rate only.
For example, assume that a service has an authorization volume of 10 megabytes and the following simplified rate structure:
From 6:00 a.m. to 6:59 a.m., $1 per megabyte
From 7:00 a.m. to 8:59 a.m., $2 per megabyte
A customer that accesses the service at 6:55 a.m. will be authorized if the account balance is at least $10 (10 megabytes x $1 per megabyte) and the authorization will be valid for 4 minutes 59 seconds. At 6:59 p.m., BRM forces a reauthorization at a rate of $2 per megabyte and with a validity period of 119 minutes 59 seconds (the time of the next rate change).
Important:
When BRM forces a reauthorization based on tariff changes, a spike in the network traffic occurs. You can reduce network spikes during a tariff change by delaying reauthorizations to distribute them more evenly. See "About Reducing Network Spikes during a Tariff Change".To determine whether a customer has sufficient resources to use a service, BRM performs the following operations:
Estimates the cost of usage by rating the event with the authorization duration or volume, such as 30 minutes or 200 bytes, and optionally applying discounts. If multiple RUMs apply to the event, the estimate includes all of them.
Calculates the customer's available resources by retrieving current balances and subtracting any active reservations.
Compares the estimated cost against the customer's available resources.
If there are sufficient resources, BRM authorizes the usage.
If there aren't sufficient resources, BRM determines the maximum that can be authorized. See "About Calculating Maximum Authorizations".
For example, assume a customer with a prepaid balance of $50 wants to use a service that costs $1 per minute and is eligible for a 10% discount. If the authorization value is 20 minutes, BRM determines whether there are sufficient resources as follows:
Estimates the cost of usage by:
Rating the event: $1 per minute x 20 minutes = $20
Applying the 10% discount: $20 – $2 = $18
Calculates the customer's available resources: $50
Compares the estimated cost against the customer's available resources: $18 is less than $50.
Because the customer has sufficient resources, BRM authorizes the usage.
For policy-driven charging sessions, BRM readjusts the quota in the following way:
Retrieves the balances for all the resources associated with the resource ID.
Retrieves all the associated offer profiles for the service POID and account POID.
Reduces the consumed quota by the consumed reserved amount in the Balances array.
Determines if the requested quota exceeds the amount available. If so, readjusts the quota to the amount that is available.
For example, the current balance on an account for a non-currency resource is 80 megabytes and the consumed reserved amount (across parallel sessions, iPhone, video, and computer) is 35 megabytes. When BRM receives a request to authorize a request for that resource and the requested amount exceeds 25 megabytes, BRM sets the allowable reservation quota for the session at 25 megabytes.
The method BRM uses to determine sufficient resources depends on whether the event is discountable and whether it involves multiple RUMs:
If an event is discountable or involves multiple RUMs, BRM first rates the event by using real-time rating opcodes. It then sends the information to a real-time discounting pipeline to apply discounts and charge sharing, calculate the customer's available resources, and compare the estimated cost against the customer's available resources.
If an event is not discountable and does not involve multiple RUMs, BRM performs all steps: rating the event, calculating the customer's available resources, and comparing the estimated cost against the available resources: by using real-time rating.
If a request cannot be fully authorized because of insufficient resources, BRM calculates the maximum amount the customer can use and authorizes that amount. For example, if a customer has a prepaid balance of $5 and wants to use a service that costs $1 per minute, the maximum amount for which the customer can be authorized is 5 minutes.
The effects of discounts, discount sharing, and charge sharing are included in the calculation of the maximum amount to authorize. For example, if the customer mentioned above is eligible for a 50% discount, the maximum usage that will be authorized is 10 minutes.
For more information about how BRM calculates maximum authorizations, see "Credit Limit Checks during Prepaid Authorization".
For policy-driven-charging sessions, BRM readjusts the requested quota based on the current balance, used reservation across all parallel sessions, and the nearest threshold configured in the offer profile.
For example, the authorization request is for 30 MB. The current balance on the account for that resource is 80 MB and the consumed reserved amount (across parallel sessions, iPhone, video, computer,) amount to 35 MB. The next threshold in the offer profile is at 140 MB. The authorization process computes the allowable reservation quota at just 25 MB. BRM sets the provisioning for the session at 25 MB.
When a prepaid session is authorized, BRM sets aside a portion of the customer's resources for the event. This prevents customers from using the resources for other services while the session is in progress. When the session ends, BRM rates the event based on the event's duration or volume and then returns any unused resources back to the customer's account balance.
For example, assume a customer has a prepaid balance of $50.
When a prepaid session is authorized for $15, BRM reserves $15 for the session and leaves $35 that the customer can apply to other prepaid services.
When the session ends and BRM determines the cost of the call to be only $5, BRM returns the remaining $10 to the customer's account balance. This updates the customer's account balance to $45.
For more information, see "Reserving Resources for Concurrent Network Sessions" in BRM Configuring and Collecting Payments.
BRM authorizes prepaid usage for a specified duration or volume. However, customers may want to use their services beyond the authorized amount. When a prepaid event is in progress and the customer consumes most of the authorized amount, BRM can reauthorize the event for continued usage.
Reauthorization for prepaid services extends the following:
The authorized duration or volume
The validity period
The reauthorization process is similar to the authorization process, except BRM changes the duration or volume used during the verification process. The value used is the original authorization amount plus the specified extension amount. For example, if the original amount was 20 minutes and the specified extension amount is 10 minutes, BRM reauthorizes usage for 30 minutes.
The extension amount is specified in the reauthorization request from the network or is based on configured default values.
To pass in the extension amount to the BRM API, see "Reauthorizing Prepaid Sessions".
To set default reauthorization volumes and durations in BRM, see "Specifying Default Authorization and Reauthorization Values".
If the new value that is checked during reauthorization exceeds the customer's resources, BRM determines the maximum amount that can be reauthorized. BRM uses the same methodology for reauthorization that it uses for authorization. See "About Calculating Maximum Authorizations".
For volume-based services, BRM forces a reauthorization during a tariff change that causes a network spike. You can reduce network spikes during a tariff change by delaying reauthorizations to distribute them more evenly. See "Using Lightweight Authorization".
Note:
If you use prepaid lightweight authorization, you can authorize customers who maintain a certain level of resources without requiring BRM to make calls to the rating and discounting engines. You can also reauthorize customers without going through the rating process as long as they maintain the level of resources you specify. See "Using Lightweight Authorization".For policy-driven charging sessions, BRM sends a notification to the network policy controller when the sum of the current balance and used reservation reaches or crosses the nearest threshold configured in the offer profile for a given service and resource ID. This notification contains information about the policy label that is applicable, the current balance, and the difference in the amount between the current balance to the next label. If necessary, the network policy controller works with BRM to set up a new provisioning policy based on the current state of the subscriber's profile and usage amount. See "Policy-Driven Charging" in BRM Setting Up Pricing and Rating.
After a session is authorized, the external network is sometimes unable to connect the service. This can occur because:
The call's destination was unavailable.
The validity period expired before the service was connected.
The customer terminated the session before the service was connected.
In this situation, BRM can cancel the authorization and return any reserved resources back to the customer's account balance.
After a prepaid session is authorized, the external network connects the call and begins collecting information about any usage, such as the duration of the session, the time of day the session occurred, and the amount of data sent or received. The external network sends this information to BRM, which records it in the BRM database or in In-Memory Database (IMDB) Cache.
When a session ends, the BRM accounting process uses this information to determine how much to charge customers for the services they used.
BRM performs the following operations during the accounting process:
Starts recording information about a prepaid session.
Updates information about an existing prepaid session.
Stops the prepaid session when the following occurs:
The session ends successfully.
The external network encounters a severe problem, shuts down abnormally, or restarts.
Sends information about the completed session to the real-time rating opcodes, which perform the following:
Rate the customer's usage.
Update the customer's prepaid account balance.
Close the associated reservation and return any unused resources back to the customer's prepaid account balance.
Store information about the session in the BRM database.
For policy-driven charging sessions:
Receives the message from the network connectivity application containing information on the service type, device ID, details about the call, and the consumed quota. It responds to the network connectivity application.
Sends a notification if there was a threshold breach.
See "Policy-Driven Charging" in BRM Setting Up Pricing and Rating for information.
For more information, see "How BRM Manages Prepaid Sessions".
To set up your system to process prepaid AAA requests for telco services, see "Setting Up a System Based on Event-Type Rating" in BRM Installation Guide.