B.1 Introduction
B.2 Charging requirements
B.2.1 Off-line charging
B.2.2 On-line charging
B.3 Charging processes
B.4 Charging scenarios
B.4.1 Charging scenarios related to off-line charging
B.4.1.1 Scenario 1: IN charging completely in the PSTN
B.4.1.2 Scenario 2: IN charging completely in the IN
B.4.1.3 Scenario 3: IN Charging shared between IN and PSTN
B.4.1.4 Scenario 4: Charging at the SCF, assisted by the SSF
B.4.2 Charging scenarios related to on-line charging
B.5 Interactions
B.5.1 Interactions with other networks concerning charging control
B.5.2 Call parties controlled by different SLs
B.5.2.1 Case 1: charging information from SSF FSM-B to SSF FSM-A
B.5.2.2 Case 2: charging information from SSF FSM-A to SSF FSM-B
B.5.2.3 Case 3: charging information from SSF FSM-A to SSF FSM-B and reverse
B.6 Framework for the charging operations in INAP
This annex provides information on how the different charging capabilities in the IN Application Part CS1 may be used. Networks may support different or additional charging capabilities then listed in this annex.
With the introduction of IN, the charging as performed by the basic call process has to be extended. With IN, charging processes can be activated in both SCPs and SSPs. When for an IN call the charging processes in the SCP have to interwork with the charging processes in the SSP, specific charging operations have to be transferred via the INAP. This annex describes the IN charging requirements from an INAP point of view. First some terminology concerning charging processes and charging capabilities is listed, followed by particular charging scenarios for which the INAP requirements are listed. Via the information flows and information elements, the corresponding charging operations for the INAP can be defined.
B.2 Charging requirements
In general two types of charging capabilities are required.
B.2.1 Off-line charging
The usage and/or charge information of the call is recorded in the network. The calculation of the charge for that call and the billing is performed in an off-line process. The information recorded could also be used for other purposes by the network operator (e.g. accounting).
B.2.2 On-line charging
In this case charging information during the call instance has to be calculated in real time. This further processing of charging information in real time could be for the support of the pay phone, AOC (advice of charge) or for charge metering.
B.3 Charging processes
Following considerations apply to the case of one service and one network.
At a high level the following processes concerning the charging can be identified:
In an IN structured network, the charging for services may be split between several parties. Each of the following scenarios shows a possible charging configuration for one of the parties. Scenarios may be combined to give the total charging capabilities required for a service. The choice of scenario for each charged party is a network specific option.
For each of the scenarios (and therefore for each charged party) there is only one point of control for IN charging per call.
B.4.1 Charging scenarios related to off-line charging
To support the off-line charging process, some charging related functions have to be executed during a call instance.
B.4.1.1 Scenario 1: IN charging completely in the PSTN
In this case (scenario 1), the charging is done by the existing charging mechanisms in the PSTN, such as using the service access code to determine the tariff, and meters in the LE to count the charge pulses. For this mechanism, no INAP operations are required, as no charging functions are performed by the SSF, SCF or any other IN FE.
B.4.1.2 Scenario 2: IN charging completely in the IN
In this scenario, the charging is done completely in the IN nodes. The PSTN will determine from e.g. the service access code, that no charge is to be raised, and all accounting will be performed at either the SSF or the SCF. The control of charging is always at the SCF, but call records may be registered at either the SSF (scenario 2.2, 2.3) or SCF (scenario 2.1) or both (scenario 2.4).
In case call records are registered at both SSF and SCF, for the same call instance there should be a correlation between both call records to allow the off-line billing process to correlate them. For this purpose the SCF should generate a unique correlationID and send it to the SSF. Both the SCF and SSF should register this in the call record.
B.4.1.3 Scenario 3: IN Charging shared between IN and PSTN
In this case, the SCF has control of the charging information and instructs the SSF on the charging information to be sent by the SSF (scenario 3.2).
In the LE, either a charge meter can be updated or a standard call record can be generated. There is no call record generated at the SSF or SCF.
If the SSF is a LE, the principles are the same, but the SSF-LE interface will be internal rather than by network signalling. The SCF need not know whether the SSP is a transit or a local exchange.
Figure B.1: Scenario 3
B.4.1.4 Scenario 4: Charging at the SCF, assisted by the SSF
The SCF has the relevant charging information to apply charging and instructs the SSF to calculate the call charge. Included in these instructions are the conditions on which the SSF should request further information from the SCF (e.g. thresholds, i.e. inform the SCF when the charge reaches a certain amount).
When the call has finished or e.g. a threshold is reached, then the SSF informs the SCF on what has happened and the SCF performs the necessary processing of the charge information, and possibly instructs the SSF what to do next (e.g. clear the call).
The calculated call charge can be registered at either the SCF (scenario 4.1) or SSF (scenario 4.2).
B.4.2 Charging scenarios related to on-line charging
Apart from the scenarios supporting the off-line charging, some networks require scenarios to support the on-line charging capability. This means that at the user/network interface charge related information (like charge pulses or signalling information) have to be offered.
If the charging is controlled by the SCF, it shall be possible to offer the charge information to the LE. The LE uses this information at the UNI. If this charge information is delivered to the LE for call recording purposes (i.e. scenario 3, scenario 4 in case SSF in LE), this information may also be used for on-line charging.
If this charge information is not delivered to the LE (i.e. scenario 2 and 4 in case SSF not in LE), then additional IFs are needed for on-line charging. In that case the same configuration described in scenario 3 could be used to transfer the charge information in addition to the off-line charging related scenario.
Flexible tariffing is a concept used in many networks. For IN calls, charge rates need to be changed at certain times to all or dedicated destinations, or per call instance dependent on the duration of the conversation or the service interactions involved.
When SCF controls the charging and on-line charging is required for a call instance, the SCF should be able to change the charge rates in the network. This on-line charging process may cause additional signalling traffic and processing load in both the IN and the PSTN/ISDN.
To avoid additional processing and signalling in the network it may be useful to apply the on-line charging selectively (i.e. only on the calls for which it is necessary, e.g. payphone or AOC). Whether on-line charging is required or not can be determined by either:
Interactions concerning the charging of an IN call can occur in the following cases:
This is the case when SSF receives charging-related signalling from a higher exchange (e.g. international exchange or dedicated service exchanges).
There are three options identified to handle this type of interaction. For a call instance controlled by the SCF, the SCF should select one of these options. According to the general requirement "there is only one point of control for charging per call party per call", the selected option will remain during the lifetime of the call instance for the call party.
This is the case for e.g. UPT to UPT or UPT to VPN calls. Interaction occurs in the following cases:
This interaction occurs when SL-B causes a charge pulse or signalling information from SSF FSM-B to SSF FSM-A.
NOTE: If both SSF FSMs reside in the same SSF, then the principles will be the same, but the SSF FSM-A/SSF FSM-B interface will be internal rather than by network signalling.There are three options identified to handle this type of interaction. For a call instance controlled by SL-A, the SL-A should select one of these options. According to the general requirement "there is only one point of control for charging per call party per call", the selected option will remain during the lifetime of the call instance for the call party.
This interaction occurs when SL-A causes a charge pulse or signalling information1) from SSF FSM-A to SSF FSM-B. To handle this type of interaction the same options apply as case 1 (i.e. SL-B selects one of the options).
B.5.2.3 Case 3: charging information from SSF FSM-A to SSF FSM-B and reverse
This interaction occurs when both SL-B causes a charge pulse or signalling information1) from SSF FSM-B to SSF FSM-A and SL-A causes a charge pulse or signalling information1) from SSF FSM-A to SSF FSM-B.
This interaction can be managed by a superposition of the principles given for the cases 1 and 2.
B.6 Framework for the charging operations in INAP
In general: