SIST ES 201 915-12 V1.4.1:2005

SLOVENSKI STANDARD
01-januar-2005
2GSUWLGRVWRSGRVWRULWYH26$±9PHVQLN]DDSOLNDFLMVNRSURJUDPLUDQMH$3,±
GHO=DUDþXQDYDQMH6&)
Open Service Access (OSA); Application Programming Interface (API); Part 12:
Charging SCF
Ta slovenski standard je istoveten z: ES 201 915-12 Version 1.4.1
ICS:
33.040.01 Telekomunikacijski sistemi Telecommunication systems
na splošno in general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

ETSI Standard
Open Service Access (OSA);
Application Programming Interface (API);
Part 12: Charging SCF
(Parlay 3)
�
2 ETSI ES 201 915-12 V1.4.1 (2003-07)

Reference
RES/SPAN-120095-12
Keywords
API, OSA, IDL, UML
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, send your comment to:
editor@etsi.org
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2003.
© The Parlay Group 2003.
All rights reserved.
TM TM TM
DECT , PLUGTESTS and UMTS are Trade Marks of ETSI registered for the benefit of its Members.
TM
TIPHON and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
3 ETSI ES 201 915-12 V1.4.1 (2003-07)
Contents
Intellectual Property Rights.5
Foreword.5
1 Scope.6
2 References.6
3 Definitions and abbreviations.6
3.1 Definitions.6
3.2 Abbreviations.6
4 Charging SCF.7
4.1 General requirements on support of methods.7
5 Sequence Diagrams.7
5.1 Reservation / payment in parts .7
5.2 Immediate Charge.9
6 Class Diagrams.11
7 The Service Interface Specifications.12
7.1 Interface Specification Format .12
7.1.1 Interface Class.13
7.1.2 Method descriptions.13
7.1.3 Parameter descriptions.13
7.1.4 State Model.13
7.2 Base Interface.13
7.2.1 Interface Class IpInterface .13
7.3 Service Interfaces.13
7.3.1 Overview.13
7.4 Generic Service Interface .14
7.4.1 Interface Class IpService .14
8 Charging Interface Classes.15
8.1 Interface Class IpChargingManager.15
8.2 Interface Class IpAppChargingManager .16
8.3 Interface Class IpChargingSession.17
8.4 Interface Class IpAppChargingSession .27
9 State Transition Diagrams.39
9.1 State Transition Diagrams for IpChargingSession .39
9.1.1 Session Created State.40
9.1.2 Amount Reserved State.40
9.1.3 Volume Reserved State.40
10 Data Definitions.40
10.1 Charging Data Definitions.40
10.1.1 IpChargingManager.40
10.1.2 IpChargingManagerRef.40
10.1.3 IpAppChargingManager.40
10.1.4 IpAppChargingManagerRef.40
10.1.5 IpChargingSession.41
10.1.6 IpChargingSessionRef.41
10.1.7 IpAppChargingSession.41
10.1.8 IpAppChargingSessionRef.41
10.1.9 TpApplicationDescription.41
10.1.10 TpAppInformationSet.41
10.1.11 TpAppInformation.41
10.1.12 TpAppInformationType.41
10.1.13 TpSessionEndedCause.42
ETSI
4 ETSI ES 201 915-12 V1.4.1 (2003-07)
10.1.14 TpMerchantAccountID.42
10.1.15 TpCorrelationID.42
10.1.16 TpCorrelationType.42
10.1.17 TpChargingPrice.42
10.1.18 TpAmount.42
10.1.19 TpChargingParameterSet.43
10.1.20 TpChargingParameter.43
10.1.21 TpChargingParameterID.43
10.1.22 TpChargingParameterValue.43
10.1.23 TpChargingParameterValueType.43
10.1.24 TpVolumeSet.43
10.1.25 TpVolume.44
10.1.26 TpUnitID.44
10.1.27 TpChargingSessionID.44
10.1.28 TpPriceVolumeSet.44
10.1.29 TpPriceVolume.44
10.1.30 TpChargingError.45
11 Exception Classes.45
Annex A (normative): OMG IDL Description of Charging SCF.46
Annex B (informative): Contents of 3GPP OSA R4 Charging.47
Annex C (informative): Record of changes .48
C.1 Interfaces.48
C.1.1 New.48
C.1.2 Deprecated.48
C.1.3 Removed.48
C.2 Methods.48
C.2.1 New.48
C.2.2 Deprecated.48
C.2.3 Modified.49
C.2.4 Removed.49
C.3 Data Definitions.49
C.3.1 New.49
C.3.2 Modified.49
C.3.3 Removed.49
C.4 Service Properties.49
C.4.1 New.49
C.4.2 Deprecated.50
C.4.3 Modified.50
C.4.4 Removed.50
C.5 Exceptions.50
C.5.1 New.50
C.5.2 Modified.50
C.5.3 Removed.50
C.6 Others.50
History .51

ETSI
5 ETSI ES 201 915-12 V1.4.1 (2003-07)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This ETSI Standard (ES) has been produced by ETSI Technical Committee Services and Protocols for Advanced
Networks (SPAN).
The present document is part 12 of a multi-part deliverable covering Open Service Access (OSA); Application
Programming Interface (API), as identified below. The API specification (ES 201 915) is structured in the following
parts:
Part 1: "Overview";
Part 2: "Common Data Definitions";
Part 3: "Framework";
Part 4: "Call Control SCF";
Part 5: "User Interaction SCF";
Part 6: "Mobility SCF";
Part 7: "Terminal Capabilities SCF";
Part 8: "Data Session Control SCF";
Part 9: "Generic Messaging SCF";
Part 10: "Connectivity Manager SCF";
Part 11: "Account Management SCF";
Part 12: "Charging SCF".
The present document has been defined jointly between ETSI, The Parlay Group (http://www.parlay.org) and the 3GPP,
in co-operation with a number of JAIN™ Community (http://www.java.sun.com/products/jain) member companies.
The present document forms part of the Parlay 3.3 set of specifications.
The present document is equivalent to 3GPP TS 29.198-12 V4.4.0 (Release 4).
ETSI
6 ETSI ES 201 915-12 V1.4.1 (2003-07)
1 Scope
The present document is part 12 of the Stage 3 specification for an Application Programming Interface (API) for Open
Service Access (OSA).
The OSA specifications define an architecture that enables application developers to make use of network functionality
through an open standardised interface, i.e. the OSA APIs.
The present document specifies the Charging Service Capability Feature (SCF) aspects of the interface. All aspects of
the Charging SCF are defined here, these being:
• Sequence Diagrams
• Class Diagrams
• Interface specification plus detailed method descriptions
• State Transition diagrams
• Data Definitions
• IDL Description of the interfaces
The process by which this task is accomplished is through the use of object modelling techniques described by the
Unified Modelling Language (UML).
2 References
The references listed in clause 2 of ES 201 915-1 contain provisions which, through reference in this text, constitute
provisions of the present document.
ETSI ES 201 915-1: "Open Service Access (OSA); Application Programming Interface (API); Part 1: Overview
(Parlay 3)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ES 201 915-1 apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations defined in ES 201 915-1 apply.
ETSI
7 ETSI ES 201 915-12 V1.4.1 (2003-07)
4 Charging SCF
The following clauses describe each aspect of the Charging Service Capability Feature (SCF).
The order is as follows:
• The Sequence diagrams give the reader a practical idea of how each of the SCF is implemented.
• The Class relationships clause show how each of the interfaces applicable to the SCF, relate to one another.
• The Interface specification clause describes in detail each of the interfaces shown within the Class diagram
part.
• The State Transition Diagrams (STD) show the transition between states in the SCF. The states and transitions
are well-defined; either methods specified in the Interface specification or events occurring in the underlying
networks cause state transitions.
• The Data Definitions clause show a detailed expansion of each of the data types associated with the methods
within the classes. Note that some data types are used in other methods and classes and are therefore defined
within the Common Data types part of the present document.
4.1 General requirements on support of methods
An implementation of this API which supports or implements a method described in the present document, shall
support or implement the functionality described for that method, for at least one valid set of values for the parameters
of that method.
Where a method is not supported by an implementation of a Service interface, the exception
P_METHOD_NOT_SUPPORTED shall be returned to any call of that method.
Where a method is not supported by an implementation of an Application interface, a call to that method shall be
possible, and no exception shall be returned.
5 Sequence Diagrams
5.1 Reservation / payment in parts
The sequence diagram illustrates how to request a reservation and how to charge a user from the reserved amount, for
instance to charge a user for a streamed video which lasts 10 minutes and costs a total of $2.00. The operations and
interfaces that do not provide rating are employed throughout this sequence diagram.
We assume the application has already discovered the Charging SCF. As a result, the application received an object
reference pointing to an object that implements the IpChargingManager interface.
The operations which handle units are used exactly the same, except that the amount of application usage is indicated
instead of a price.
ETSI
8 ETSI ES 201 915-12 V1.4.1 (2003-07)
Application : IpAppChargingSession : IpChargingManager : IpChargingSession
1: new()
2: createChargingSession(   )
3: new()
4: reserveAmountReq(   )
5: reserveAmountRes(   )
6: forward event()
7: debitAmountReq(   )
8: debitAmountRes(   )
9: forward event()
10: getLifeTimeLeft( )
11: extendLifeTimeReq( )
12: extendLifeTimeRes( )
13: forward event()
14: debitAmountReq(   )
15: debitAmountRes(   )
16: forward event()
17: release( )
1: The application creates a local object implementing the IpAppChargingSession interface. This object will
receive response messages from the IpChargingSession object.
2: The application opens a charging session, a reference to a new or existing object implementing
IpChargingSession is returned together with a unique session ID.
3: In this case a new object is used.
4: The application requests the reservation of $2.00.
ETSI
9 ETSI ES 201 915-12 V1.4.1 (2003-07)
5: Assuming the criteria for requesting a reservation are met (the application provider has permission to charge
the requested amount, the charged user has agreed to pay the requested amount), the amount is reserved in the
session. At this point, the application provider knows that the network operator will accept later debit requests
up to the reserved amount. So, the application may start serving the user, for instance by sending the video
stream.
6: The successful reservation is reported back to the application.
After half of the video has been sent to the user, the application may choose to capture half of the price already:
7: The application requests to debit $1.00 from the reservation.
8: The successful debit is reported back to the application.
9: The acknowledge is forwarded to the application.
10: The application checks if the remaining lifetime of the reservation will cover the remaining 5 minutes of video.
Let us assume, it does not.
11: The application asks the IpChargingSession object to extend the lifetime of the reservation.
12: Assuming that the application provider is allowed to keep reservations open for longer than 10 minutes, the
extendLifeTimeReq() will be honoured and confirmed properly.
13: The confirmation is forwarded to the application.
14: When the complete video has been transmitted to the user without errors, the application charges another
$1.00.
15: The IpChargingSession object acknowledges the successful debit at the IpAppChargingSession callback
object.
16: The IpAppChargingSession object forwards the acknowledge to the application.
17: Since the service is complete, the application frees all resources associated with the reservation and session.
5.2 Immediate Charge
This sequence diagram illustrates how immediate charging is used. Assume a WAP gateway that charges the user $0.01
per requested URL. Since it is acceptable to loose one tick worth $0.01, no prior reservations are made. The WAP
gateway sends an immediate debit for each requested URL, and should a payment have as result failure, the user is
disconnected.
The operations which handle units are used exactly the same, except that the amount of application usage is indicated
instead of a price.
ETSI
10 ETSI ES 201 915-12 V1.4.1 (2003-07)
Application : IpAppChargingSession : IpChargingManager : IpChargingSession
1: new()
2: createChargingSession(   )
3: directDebitAmountReq(   )
4: directDebitAmountRes(  )
5: forward notification
6: directDebitAmountReq(   )
7: directDebitAmountErr(  )
8: forward notification
9: release( )
1: The application creates a local object implementing the IpAppChargingSession interface. This object will
receive response messages from the IpChargingSession object.
2: The application orders the creation of a session. No new object is created for the charging session handling in
this example implementation.
3: The application requests to charge the user $0.01.
4: The payment is acknowledged.
5: The acknowledgement is forwarded in the application.
6: The application requests to charge the user $0.01.
7: The payment is reported to fail.
8: The failure report is forwarded in the application.
(repeat steps 3 - 5 and 6 - 8 as long as you want to in any order you want to)
9: The application releases the session.
ETSI
11 ETSI ES 201 915-12 V1.4.1 (2003-07)
6 Class Diagrams
This class diagram shows the application interfaces for charging and their relations to the service interfaces.
IpInterface
(from csapi)
IpAppChargingSession
(from cs)
creditAmountErr()
creditAmountRes()
IpChargingSession
creditUnitErr()
(from cs)
creditUnitRes()
debitAmountErr()
creditAmountReq()
debitAmountRes()
creditUnitReq()
debitUnitErr()
debitAmountReq()
debitUnitRes()
debitUnitReq()
directCreditAmountErr()
directCreditAmountReq()
directCreditAmountRes()
directCreditUnitReq() <>
directCreditUnitErr()
directDebitAmountReq()
directCreditUnitRes()
directDebitUnitReq()
directDebitAmountErr()
extendLifeTimeReq()
directDebitAmountRes()
getAmountLeft()
directDebitUnitErr()
getLifeTimeLeft()
directDebitUnitRes()
getUnitLeft()
extendLifeTimeErr()
rateReq()
extendLifeTimeRes()
release()
rateErr()
reserveAmountReq()
rateRes()
reserveUnitReq()
reserveAmountErr()
reserveAmountRes()
0.n
reserveUnitErr()
reserveUnitRes()
sessionEnded()
0.n
IpChargingManager IpAppChargingManager
(from cs) <> (from cs)
createChargingSession() sessionAborted()

Figure 1: Application Interfaces
This class diagram shows the interfaces of the charging SCF.
ETSI
12 ETSI ES 201 915-12 V1.4.1 (2003-07)
<>
IpService
(f rom csap i)
setCallback()
setCallbackWithSessionID()
<>
<>
IpChargingSession
IpChargingManager
(from cs)
(from cs)
creditAmountReq()
createChargingSession()
creditUnitReq()
debitAmountReq()
debitUnitReq()
directCreditAmountReq()
directCreditUnitReq()
directDebitAmountReq()
directDebitUnitReq()
extendLifeTimeReq()
getAmountLeft()
getLifeTimeLeft()
getUnitLeft()
rateReq()
release()
reserveAmountReq()
reserveUnitReq()
Figure 2: Service Interfaces
7 The Service Interface Specifications
7.1 Interface Specification Format
This clause defines the interfaces, methods and parameters that form a part of the API specification. The Unified
Modelling Language (UML) is used to specify the interface classes. The general format of an interface specification is
described below.
ETSI
13 ETSI ES 201 915-12 V1.4.1 (2003-07)
7.1.1 Interface Class
This shows a UML interface class description of the methods supported by that interface, and the relevant parameters
and types. The Service and Framework interfaces for enterprise-based client applications are denoted by classes with
name Ip. The callback interfaces to the applications are denoted by classes with name IpApp. For
the interfaces between a Service and the Framework, the Service interfaces are typically denoted by classes with name
IpSvc, while the Framework interfaces are denoted by classes with name IpFw
7.1.2 Method descriptions
Each method (API method "call") is described. Both synchronous and asynchronous methods are used in the API.
Asynchronous methods are identified by a 'Req' suffix for a method request, and, if applicable, are served by
asynchronous methods identified by either a 'Res' or 'Err' suffix for method results and errors, respectively. To handle
responses and reports, the application or service developer must implement the relevant IpApp or
IpSvc interfaces to provide the callback mechanism.
7.1.3 Parameter descriptions
Each method parameter and its possible values are described. Parameters described as 'in' represent those that must have
a value when the method is called. Those described as 'out' are those that contain the return result of the method when
the method returns.
7.1.4 State Model
If relevant, a state model is shown to illustrate the states of the objects that implement the described interface.
7.2 Base Interface
7.2.1 Interface Class IpInterface
All application, framework and service interfaces inherit from the following interface. This API Base Interface does not
provide any additional methods.
<>
IpInterface
7.3 Service Interfaces
7.3.1 Overview
The Service Interfaces provide the interfaces into the capabilities of the underlying network - such as call control, user
interaction, messaging, mobility and connectivity management.
The interfaces that are implemented by the services are denoted as 'Service Interface'. The corresponding interfaces that
must be implemented by the application (e.g. for API callbacks) are denoted as 'Application Interface'.
ETSI
14 ETSI ES 201 915-12 V1.4.1 (2003-07)
7.4 Generic Service Interface
7.4.1 Interface Class IpService
Inherits from: IpInterface
All service interfaces inherit from the following interface.
<>
IpService
setCallback (appInterface : in IpInterfaceRef) : void
setCallbackWithSessionID (appInterface : in IpInterfaceRef, sessionID : in TpSessionID) : void

Method
setCallback()
This method specifies the reference address of the callback interface that a service uses to invoke methods on the
application. It is not allowed to invoke this method on an interface that uses SessionIDs.
Parameters
appInterface : in IpInterfaceRef
Specifies a reference to the application interface, which is used for callbacks
Raises
TpCommonExceptions, P_INVALID_INTERFACE_TYPE

Method
setCallbackWithSessionID()
This method specifies the reference address of the application's callback interface that a service uses for interactions
associated with a specific session ID: e.g. a specific call, or call leg. It is not allowed to invoke this method on an
interface that does not use SessionIDs.
Parameters
appInterface : in IpInterfaceRef
Specifies a reference to the application interface, which is used for callbacks
sessionID : in TpSessionID
Specifies the session for which the service can invoke the application's callback interface.
Raises
TpCommonExceptions, P_INVALID_SESSION_ID, P_INVALID_INTERFACE_TYPE

ETSI
15 ETSI ES 201 915-12 V1.4.1 (2003-07)
8 Charging Interface Classes
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 1 000. During the period that the response
to the original request (which also carries the next request number to use equal to 1 000) 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.
8.1 Interface Class IpChargingManager
Inherits from: IpService.
This interface is the 'service manager' interface for the Charging Service. The Charging manager interface provides
management functions to the charging service. The application programmer can use this interface to start charging
sessions.
This interface and the createChargingSession() method shall be implemented by a Charging SCF.
<>
IpChargingManager
createChargingSession (appChargingSession : in IpAppChargingSessionRef, sessionDescription : in
TpString, merchantAccount : in TpMerchantAccountID, user : in TpAddress, correlationID : in
TpCorrelationID) : TpChargingSessionID

Method
createChargingSession()
This method creates an instance of the IpChargingSession interface to handle the charging events related to the
specified user and to the application invoking this method.
Returns chargingSession: Defines the session.
ETSI
16 ETSI ES 201 915-12 V1.4.1 (2003-07)
Parameters
appChargingSession : in IpAppChargingSessionRef
Callback interface for the session in the application
sessionDescription : in TpString
Descriptive text for informational purposes.
merchantAccount : in TpMerchantAccountID
Identifies the account of the party providing the application to be used.
user : in TpAddress
Specifies the user that is using the application. This may or may not be the user that will be charged. The Charging
service will determine the charged user. When this method is invoked the Charging service shall determine if charging
is allowed for this application for this subscriber. An exception shall be thrown if this type of charging is not allowed.
correlationID : in TpCorrelationID
This value can be used to correlate the charging to network activity.
Returns
TpChargingSessionID
Raises
TpCommonExceptions, P_INVALID_USER, P_INVALID_ACCOUNT

8.2 Interface Class IpAppChargingManager
Inherits from: IpInterface.
This interface is the manager application interface for the Charging Service. The Charging manager interface provides
the application Charging Session Management functions to the charging service.
<>
IpAppChargingManager
sessionAborted (sessionID : in TpSessionID) : void

Method
sessionAborted()
This method indicates to the application that the charging session object (at the gateway) has aborted or terminated
abnormally. No further communication will be possible between the charging session and application.
ETSI
17 ETSI ES 201 915-12 V1.4.1 (2003-07)
Parameters
sessionID : in TpSessionID
Specifies the sessionID of the charging session that has aborted or terminated abnormally.
8.3 Interface Class IpChargingSession
Inherits from: IpService.
The Charging Session interface provides operations to facilitate transactions between a merchant and a user. The
application programmer can use this interface to debit or credit amounts and/or units towards a user, to create and
extend the lifetime of a reservation and to get information about what is left of the reservation.
This interface shall be implemented by a Charging SCF. As a minimum requirement, the release() method shall be
implemented. If the reserveAmountReq() method is implemented, at least one of the debitAmountReq() or
creditAmountReq() methods shall also be implemented. If the reserveUnitReq() method is implemented, at least one of
the debitUnitReq() or creditUnitReq() methods shall also be implemented. If neither the reserveAmountReq() nor the
reserveUnitReq() method is implemented, then at least one of the directDebitAmountReq() or the directDebitUnitReq(),
or the directCreditAmountReq(), or the directCreditUnitReq() methods shall be implemented.
ETSI
18 ETSI ES 201 915-12 V1.4.1 (2003-07)
<>
IpChargingSession
creditAmountReq (sessionID : in TpSessionID, applicationDescription : in TpApplicationDescription, amount
: in TpChargingPrice, closeReservation : in TpBoolean, requestNumber : in TpInt32) : void
creditUnitReq (sessionID : in TpSessionID, applicationDescription : in TpApplicationDescription, volumes :
in TpVolumeSet, closeReservation : in TpBoolean, requestNumber : in TpInt32) : void
debitAmountReq (sessionID : in TpSessionID, applicationDescription : in TpApplicationDescription, amount :
in TpChargingPrice, closeReservation : in TpBoolean, requestNumber : in TpInt32) : void
debitUnitReq (sessionID : in TpSessionID, applicationDescription : in TpApplicationDescription, volumes : in
TpVolumeSet, closeReservation : in TpBoolean, requestNumber : in TpInt32) : void
directCreditAmountReq (sessionID : in TpSessionID, applicationDescription : in TpApplicationDescription,
chargingParameters : in TpChargingParameterSet, amount : in TpChargingPrice, requestNumber : in
TpInt32) : void
directCreditUnitReq (sessionID : in TpSessionID, applicationDescription : in TpApplicationDescription,
chargingParameters : in TpChargingParameterSet, volumes : in TpVolumeSet, requestNumber : in
TpInt32) : void
directDebitAmountReq (sessionID : in TpSessionID, applicationDescription : in TpApplicationDescription,
chargingParameters : in TpChargingParameterSet, amount : in TpChargingPrice, requestNumber : in
TpInt32) : void
directDebitUnitReq (sessionID : in TpSessionID, applicationDescription : in TpApplicationDescription,
chargingParameters : in TpChargingParameterSet, volumes : in TpVolumeSet, requestNumber : in
TpInt32) : void
extendLifeTimeReq (sessionID : in TpSessionID) : void
getAmountLeft (sessionID : in TpSessionID) : TpChargingPrice
getLifeTimeLeft (sessionID : in TpSessionID) : TpInt32
getUnitLeft (sessionID : in TpSessionID) : TpVolumeSet
rateReq (sessionID : in TpSessionID, chargingParameters : in TpChargingParameterSet) : void
release (sessionID : in TpSessionID, requestNumber : in TpInt32) : void
reserveAmountReq (sessionID : in TpSessionID, applicationDescription : in TpApplicationDescription,
chargingParameters : in TpChargingParameterSet, preferredAmount : in TpChargingPrice,
minimumAmount : in TpChargingPrice, requestNumber : in TpInt32) : void
reserveUnitReq (sessionID : in TpSessionID, applicationDescription : in TpApplicationDescription,
chargingParameters : in TpChargingParameterSet, volumes : in TpVolumeSet, requestNumber : in
TpInt32) : void
Method
creditAmountReq()
This method credits an amount towards the reservation associated with the session.
The amount left in the reservation will be increased by this amount.
Each request to debit / credit an amount towards a reservation is handled separately. For example, two requests for a
payment of EUR 1,- will give a total payment of EUR 2,-.
A credit of EUR 1,- and a debit of EUR 1 will give a total payment of EUR 0,-.
ETSI
19 ETSI ES 201 915-12 V1.4.1 (2003-07)
Parameters
sessionID : in TpSessionID
The ID of the session.
applicationDescription : in TpApplicationDescription
Descriptive text for informational purposes (e.g. text presented on the bill and used in communication towards the user)
amount : in
...