Tech-invite   World Map
3GPPspecs     Glossaries     T+       IETF     RFCs     Groups     SIP     ABNFs
Top        in Index        Prev        Next

TS 29.198-12 (CT)
Open Service Access (OSA) API
Part 12: Charging Service Capability Feature

ToC      3GPP‑Page      ETSI‑search      Help       
V9.0.0 (PDF)    2009/12    58 p.
V8.0.0    2008/12    58 p.
V7.0.0    2007/03    58 p.
V6.5.1    2006/07    58 p.
V5.9.0    2005/12    54 p.
V4.6.0    2005/12    50 p.

Rapporteur:  Mr. Unmehopa, Musa
See also:  TS 29.198    

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.


Here        Top



1   Scope   PDF-p. 8
2   References
3   Definitions and abbreviations   PDF-p. 9
4   Charging SCF
5   Sequence Diagrams
6   Class Diagrams   PDF-p. 13
7   The Service Interface Specifications   PDF-p. 14      Up
8   Charging Interface Classes   PDF-p. 17
8.1   Interface Class IpChargingManager
8.2   Interface Class IpAppChargingManager   PDF-p. 19
8.3   Interface Class IpChargingSession
8.4   Interface Class IpAppChargingSession   PDF-p. 30
9   State Transition Diagrams
10   Content Based Charging Service Properties      Up
11   Data Definitions   PDF-p. 45
12   Exception Classes
A  (Normative)   OMG IDL Description of Charging SCF   PDF-p. 51
B   W3C WSDL Description of Charging SCF   PDF-p. 52
C   Java™ API Description of the Charging SCF   PDF-p. 53
D   Description of Charging for 3GPP2 cdma2000 networks   PDF-p. 54
E   Change history   PDF-p. 56

Up        Top