The Charging SCF is used by applications to charge for the usage of the applications. The charged user can be the same user as that uses the application. It is also possible that another user will pay the charge.
In the interfaces of the Charging SCF a "Request Number" is used when invoking operations that operate on the user's account (directly or indirectly via reservations) in order to make retries possible after application, service, or communication errors. A retry of these operations can be done by invoking the same operation with the same Request Number.
In the callback to the application, the Request Number to be used for the next request operation is returned. This is the only Request Number besides the one in the last request operation that can be used. This mechanism ensures that an application retries an operation when it does not receive an answer.
The use of the Request Number ensures that there can only be one outstanding request per Charging Session. Only after an answer is received (result or error), the next request can be made. Note however that only asynchronous operations that could lead to over or under charging of the user require a request number.
Because responses from the Charging SCF can be delayed in the network the Charging SCF shall guarantee that
Request Numbers are unique in a timespan where delayed responses can arrive. Suppose, for example, that the response from a retried request is received indicating the next request number to use is 1000. During the period that the response to the original request (which also carries the next request number to use equal to 1000) can arrive, this request number may not be used again.
The units (of different types) that are used in a TpVolumeSet
are NOT consolidated by the charging SCF. The
application must use the same units when making the reservation and when debiting the amount. For example, when
after a reservation of 10 minutes a debit request for 5 seconds is done, an error will be returned.
There are cases where a single instance of the merchant application may serve more than a one service user. Examples are multi-user games or conferences. Typically, the costs for the resources consumed by the single service instance will be split among all service users.
On the other hand, a merchant application may show advertisements within its application, and in turn the company that is advertised may subside a certain percentage of the application cost. A consumer connecting to the merchant
application pays only part of the costs, while the remainder is paid by the advertised company.
To support this kind of application, multiple users can be specified when a charging session is created. The charging session interface itself is the same no matter if the split charging feature is used or not.
It is subject to service level agreements that are negotiated between the OSA client provider and the network operator how the charge is split between the users.