Billing for time-based services

Traditionally, the billing of specific user activity (e.g., a phone call) has been done only in the context of a particular session. This means that, when a call is completed, the billing engine calculates the charges for the call based on price parameters for the call destination and duration. This amount is then applied to the account, customer or vendor balance. This process does not take into consideration any other previous activity of the user (e.g., phone calls already made during this billing period).

Volume discount plans allow rating of service consumption based not just on information about a particular isolated event, but are able to dynamically adjust billing with regard to previously consumed service (e.g., if you have made more than 500 minutes of calls to US&Canada this month already, the current call will be charged at a 10% discount to the standard rate).

It is possible to have different sets of prices for peak and off-peak time. Off-peak periods are defined using the powerful and flexible Time::Period module. Refer to the Creating a Service with Multiple Off-Peak Periods handbook for the steps to define off-peak periods and set different prices for them.

The fundamental concept here is the period definition, which specifies a certain interval in time (typically a repeating one). In each period you can specify conditions for:

• Time of day
• Day of week
• Day of month
• Month

If you do not specify a condition for a certain element (e.g., for Month) then it is considered that there are no limitations on this element, e.g. “from 8 PM to 8 AM” will apply in the same fashion throughout the year. If you define conditions for several elements, these must be satisfied at the same time, e.g., “from 8 PM to 8 AM, Monday-Friday” means that an event fits into this interval if it happens between 8 PM and 8 AM and from Monday through Friday, e.g., 6 AM Saturday is excluded.

An off-peak period can be a combination of several definitions so that a given moment is considered to be within the off-peak period if it satisfies at least one of these definitions. For instance, for the period “from 8 PM to 8 AM, Monday–Friday OR Saturday–Sunday” both 9 AM Saturday (since it satisfies the second condition) and 6 AM Friday (since it satisfies the first condition) are included.

By default, everything is considered to be peak time. You may use one of the three available options to determine whether a peak or off-peak rate should be used. When defining an off-peak period, you may choose for off-peak rates to be applied if:

• a call starts during off-peak time;
• a call finishes during off-peak time;
• a call both starts and finishes during off-peak time (the least flexible option).

It is also possible to offer two distinctive off-peak periods (e.g., different prices for calls made overnight or on weekends). You can define two independent off-peak periods by enabling the MultiOffPeakPeriod configuration option. In order to add a second off-peak period definition in the Off-peak Period Wizard, create your first off-peak period, then use the Add another period button. In order to use different rates for two off-peak periods, you must define prices in tariff rates for first and second off-peak periods.

So, for instance, in order to use the 0.10 rate during peak hours, 0.08 during weekends and 0.06 during night time, you should specify the main off-peak period as “8 PM–8 AM” and the alternative one as “Saturday and Sunday”, and enter the following in the rate data:

• Peak price_first, price_next = 0.10
• Off-peak price_first, price_next = 0.06
• Second off-peak price_next, price_next = 0.08

The figure above demonstrates how calls are charged. A Connect Fee is charged immediately upon connection, and all calls shorter than the First interval will be rounded to First interval seconds. Free seconds are granted after the First interval, so this part of the call is not charged. Calls longer than (First interval+Free seconds) will be rounded up to multiple Next interval seconds. After that, the Post Call Surcharge is applied. The call illustrated in the figure above will be charged using the following formula:

Amount_Charged = (Connect_Fee + First_Interval * Price_First/60 + 8 * Next_Interval * Price_N/60) * (1+Post_Call_Surcharge/100)

Parameters such as First interval, Next interval, Price First and Price Next can be specified per destination. Connect Fee, Free Seconds and Post Call Surcharge are defined on a per-tariff basis, and so will be the same for all destinations within a tariff.

This method gives you maximum flexibility for call rating. You create a call formula and then apply it to the call. This formula can consist of an unlimited number of charge elements (the only limit is the length of the formula text). These elements are interval, fixed surcharge, and relative surcharge.

• Interval – is the charged part of a call’s duration. The parameters for this element are:
  • Count – an increment that consists of one rounding period.
  • Duration – a rounding period measured in seconds.
  • Price per minute – the cost charged per call minute.

  The charge for an interval is then calculated as follows:

  Interval total = Count * (Duration/60) * Price per minute.

  For example: You configure the interval to have the following parameters:

  • Count – >
  • Duration – 10 seconds
  • Price per minute – $ 0.10

  Thus, the interval total is $0.50 as 3 * (10/60) * 0.10=0.50.

  Since a count is an increment consisting of one rounding period (i.e. 10 seconds), the number of counts is defined by the call duration. A count is rounded up when the call exceeds the interval duration. For instance, a call lasting 9 seconds is considered to have 1 count, while a call lasting 13 seconds has 2 counts.

  Therefore, if a user makes a call that lasts 35 seconds, PortaBilling calculates the charge according to the following parameters: duration – 10 seconds, counts – 4, price per minute – $0.10. Therefore, the user is charged $0.67 for this call.

  Accordingly, you can create intervals such as “First 10 minutes – price per minute is $0.05 and we will round it up to 30 seconds” – so in this case, the price per minute will be 0.05, the duration 30, and the count 20 (because there are twenty 30-second intervals in 10 minutes).

• Fixed Surcharge – is a fixed amount added to the call cost at the moment when this amount is applied, namely, following a certain interval.
• Relative Surcharge – is a percentage of the value (the total sum of the charges for preceding intervals and previously applied surcharges) to be added to the call cost. This amount can be added either at the moment it is applied (following a number of charged elements) or at the end of the call.
• Call Disconnect – is an option for forcibly disconnecting calls.
  If the Credit limit is not set for a customer or a credit account with an individual credit limit, the Call Disconnect option won’t work, even with a 100% probability of disconnecting a call.

Formula elements are applied until there is no more non-charged call duration left. The surcharges which follow a certain interval are applied only if this interval has been fulfilled. “Fulfilled” means that the interval is covered completely, i.e. the remaining call duration was enough to cover the Count * Duration time.

Let’s take an example; if we construct the formula:

• 3 * 60 seconds, 0.10/min;
• Fixed surcharge 0.05;
• N * 60 seconds, 0.10/min.

Then, when a call is made for 1 minute and 5 seconds, the charged amount will be 0.20 – in the first interval we use two increments of 60 seconds each, with price per minute 0.10. Since this first interval is to contain three increments, and we have used only two, the surcharge which follows the interval is not applied.

When a call is made for 4 minutes and 20 seconds, the total charged amount will be 0.55: three increments of 60 seconds each, a surcharge of 0.05, and then another two increments of 60 seconds with price per minute 0.10.

There is one exception to the surcharge application rule above: if the last formula element is a surcharge, it is always applied. This allows emulation of the “post-call surcharge” from earlier releases.

The figure above demonstrates how calls are charged. For example, the rating scheme “Charge 0.10 connection fee, then first 10 minutes should be rounded up to half a minute with price per minute 0.05. If the customer calls for more than 10 minutes, apply 0.10 fee and round the rest of the call up to 1 minute with price per minute 0.05; apply 5% post-call surcharge at the end of the call” will be translated into the following formula:

• Fixed surcharge 0.10;
• Interval 20 x 30 seconds, price per minute 0.05;
• Fixed surcharge 0.10;
• Interval N x 60 seconds, price per minute 0.05;
• Relative surcharge 5%.

Most often you would like to set up a general call rating scheme (rounding, surcharges, etc.) immediately, even though you foresee that your rates per minute will change in the future. In this case, you may construct the formula as you would normally do, but instead of entering a fixed price per minute in the formula you can specify: “use the current value of the Price_Next parameter”. Later, when you decide to change your rates, it will be much easier to download the current rate data, alter just one column (Price_Next), and upload the file again, rather than change the formula in every row. Also, using the pseudo-variables First Price and Next Price is required to ensure that the correct rate is used during the off-peak period, since the system will then automatically populate the variables with the values you specified for either peak or off-peak prices. Of course, if you entered a constant price value into the formula it will remain unchanged regardless of the off-peak period.

Using formula parameters linked to rate values has another advantage: if you have different prices or interval durations in peak/off-peak periods, the system will automatically use the one applicable.

Unfortunately, this is a common problem: for some destinations (usually where analog lines are used) your vendor will report the call as connected once the remote phone starts ringing. So, even if no one picks up the phone, such calls will still be considered successful by your system, with a duration (for instance) of 15 seconds, and the customer will be charged for them – which will probably lead to disputes and arguments. Using the new call rating formula, you can specify that short calls to a specific destination be disregarded. So, if you set the Do not bill calls shorter than parameter to 20 for a certain destination, and if a call lasts less than 20 seconds, it will not be billed at all. However, if the call was made for 20 or more seconds, it will be charged for the full call duration.

A rate that is marked as reverse contains exactly the same set of parameters as the normal rate. The total amount is calculated according to the same rules as described above – with the exception that this amount is then credited to the customer’s account.

This allows for “awarding back” money to the customer for certain types of service (e.g., when he receives an incoming call).

The only difference between ordinary rating and rating according to reverse rates is that volume discounts do not apply for transactions produced according to reverse rates (the current discount has no effect on the credited amount, and volume discount counters are not updated for such transactions).

While calls are normally rated based on the destination number, in some situations (e.g., charging the owner of a toll-free number for incoming calls) the caller’s number needs to be used to calculate billing charges (e.g., toll-free number costs are higher if the call originates from Alaska rather than from the 48 contiguous states).

Instead of using the default mode, where the billing engine looks up a matching rate based on the destination number (also called CLD or DNIS), it is possible to use an alternative method where the caller number (also called the CLI or ANI) is used to find the rate.

In calculating CDRs for vendors, the rating switch is done in the connection settings. So you can have some “normal” connections to a vendor, where calls are charged based on CLD/DNIS, and others where the rating is done based on the caller number (CLI/ANI). Also part of the connection configuration is the access code, which is used to apply a tariff to the customer who receives a call (please see more details in the Unified PortaSwitch Handbook Collection about the specific functionality available.).

For customer billing the configuration is done in the product. A VoIP from vendor connection which will initiate billing by ANI/CLI contains the access code used to select the applicable tariff in the product when the customer is billed. Then, in the Usage Charges configuration of the product, the administrator will add an entry with that access code and set the Rate Match Mode parameter to “Calling Number”. This allows the use of one product that will contain both “normal” tariffs (applied to outgoing calls when the call is billed by CLD) and “ANI-based” tariffs (applied to incoming DID calls).

PortaBilling offers an extremely flexible rating and authorization engine for providing prepaid calling card service. It contains the most comprehensive set of special features required for this type of service. Please see more details in the Unified PortaSwitch Handbook Collection about the specific functionality available.

Time-based services such as WiFi access, where the cost depends on the total session duration, are rated exactly the same as voice calls.

Always-on services are those which are consumed without interruption over extended periods of time. The only thing that varies is the rate of consumption. For instance, a computer connected to the Internet is constantly transferring data. However, the amount tends to be very low at night, when no one is using the computer, and higher during the day, when emailing or web browsing are taking place. It can even be extremely high when content like video-on-demand is being downloaded.

The biggest challenge when charging for services such as data downloads is that, although the customer uses the service all the time, some specific, “finite” entries must appear on his invoice, e.g., “Data downloaded May 1st–May 31st.” Also, customers expect to see real-time information about the charges applied, as in the case of other types of services.

Normally, PortaBilling receives information about service usage via “keep-alive” (or “update”) requests. Each of these informs billing that the session is still in progress and what the current service consumption is (e.g., the amount of currently downloaded and uploaded data). For each such request, PortaBilling determines which billing session it relates to. For example, although from the customer’s point of view the session did not terminate at midnight on June 1st, this was nonetheless the end of his billing period, and a new billing session has started, with charges accumulating to a new xDR. When processing an update request, PortaBilling calculates the new amount to be charged for session activity up to the present moment and updates the xDR for the session accordingly. This billing method, i.e. constantly modifying an xDR record to reflect the new charged amount, is quite different from the one used for other types of services, where PortaBilling receives the information only after the service has been completely consumed, and so the xDR is created only once.

PortaBilling’s open architecture allows processing virtually any type of “always-on” service. Take electricity billing, for example, your household consumes electricity non-stop, but consumption is lower during the night (when only the refrigerator is running), higher during the evening (when the lights are on), and extremely high during the day (when various appliances are in use).