B.1 Introduction

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:

Charge determination process (DET):

Determining the charge party. Charge party can be the calling line or IN service subscriber or both.
Determining the level of charge.
Determining the items to be charged.
If determination of the previous elements is performed off-line then in that case only a default call record is registered.

Charge generation process (GEN):

Generation of charge pulses or charge related signalling or charge related information for the off-line process.

Charge registration process (REG):

Updating the charge meters or creating call records or both.

On-line Charge Information provision to the user access (ONC):

Provision of charge pulses or signalling information on the user/network interface during call instance.

Charge Output Process (OUT):

Output of charging data for further processing. Charging data can be output to magnetic tapes or datalinks, on operator request or scheduled.

Off-line charging/billing/accounting process (OFC):

A FE which processes the call records retrieved from the other FEs (SSF, SCF, international exchange, LE) to prepare the bill for the subscriber or to support other accounting processes.

B.4 Charging scenarios

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:

an on-line charging indication from PSTN/ISDN to IN or
the SL (e.g. based on serviceKey, user service profile or user interaction)

B.5 Interactions

Interactions concerning the charging of an IN call can occur in the following cases:

1)a higher exchange generating charge related signalling towards the SSP.
2)call parties controlled by different SLs.

B.5.1 Interactions with other networks concerning charging control

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.

Option 1: In this option SCF has control of the charging information and instructs SSF to monitor and intercept the charge related signalling message(s) (from ISUP and not charge pulses) received from a higher exchange. Based on criteria supplied by the SCF, the SSF will send this information to the SCF:

1)immediately after receipt of the appropriate message type;
2)after receipt of a specified number of messages of the appropriate type; or
3)at the end of the call.
Subsequently SCF may use this information performing its charging control (use the received charging information in the call record generation or to adjust new charge rates/pulses to be sent to the SSF for on-line charging).

Option 2: The SCF may also decide to leave the charge control to the higher exchange and monitor the charging events. In this case the SCF instructs SSF to use normal charging processing, e.g. send charge signalling information and/or charge pulses through to the LE and/or update charge meters according to the received charging information from the higher exchange, and to notify the SCF. Based on criteria supplied by the SCF, the SSF will send this information to the SCF:

1)immediately after receipt of the appropriate message type;
2)after receipt of a specified number of messages of the appropriate type; or
3)at the end of the call.

Option 3: Same case as for option 2 except that the SCF does not wish to monitor the charging events.

B.5.2 Call parties controlled by different SLs

This is the case for e.g. UPT to UPT or UPT to VPN calls. Interaction occurs in the following cases:

case 1:SL-B causes charging information from SSF FSM-B towards SSF FSM-A;
case 2:SL-A causes charging information from SSF FSM-A towards SSF FSM-B;
case 3:case 1 and case 2.

B.5.2.1 Case 1: charging information from SSF FSM-B to SSF FSM-A

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.

Option 1: In this option SL-A has control of the charging information for the A-party and instructs SSF FSM-A to monitor and intercept the charge related messages received from SSF FSM-B and send it to the SL-A. Based on criteria supplied by the SL-A the SSF will send this information to the SL-A:

1)immediately after receipt of the appropriate message type;
2)after receipt of a specified number of messages of the appropriate type; or
3)at the end of the call.
Subsequently SL-A may use this information performing its charging control (use the received charging information in the call record generation, adjust new charge rates/pulses to be sent to the SSF FSM-A for on-line charging mechanism).

Option 2: The SL-A may also decide to leave the charge control to the SL-B but monitor the charging events. In this case the SL-A instructs SSF FSM-A to use normal charging processing, e.g. send charge signalling information and/or charge pulses through to the LE and/or update charge meters according to the received charging information from the SSF FSM-B, and to notify the SL-A. Based on criteria supplied by the SCF, the SSF will send this information to the SCF:

1immediately after receipt of the appropriate message type;
2after receipt of a specified number of messages of the appropriate type; or
3at the end of the call.

Option 3: Same case as for option 2 except that SL-A does not wish to monitor the charging events.

B.5.2.2 Case 2: charging information from SSF FSM-A to SSF FSM-B

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:

the starting point for the INAP work on charging is one service and one network;
charging scenario(s) are pre-defined per service. The decision to perform DET/GEN/REG in the SSF or SCF can be made on a per call basis by the SCF;
the processes OFC and OUT are not listed in the framework, as they have no impact on the scenarios defined. INAP Contents Page