SIST ES 201 915-11 V1.4.1:2005

• Abstract:

  Maintenance update of ES 201 915-11 v.1.3.1. Updated document will also be known as Parlay 3.3. Only those parts requiring modification will be updated ( most parts require maintenance fixes )

• Status: Published
• Publication Date: 31-Dec-2004
• ICS: 33.040.01 - Telecommunication systems in general
• Technical Committee: SPN - Services and Protocols for Networks
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 01-Jan-2005
• Due Date: 01-Jan-2005
• Completion Date: 01-Jan-2005
• Ref Project: ETSI ES 201 915-11 V1.4.1 (2003-07) - Open Service Access (OSA); Application Programming Interface (API); Part 11: Account Management SCF (Parlay 3)

SIST ES 201 915-11 V1.4.1:2005 is the Slovenian equivalent of ETSI ES 201 915-11 V1.4.1 for Open Service Access (OSA) Application Programming Interface (API), Part 11: Account Management SCF (Parlay 3). It specifies the account management interface used to query balances, receive charging-event notifications, and retrieve transaction histories through the OSA APIs. The document is aimed at application developers and service implementers working with telecom network functionality.

What does SIST ES 201 915-11 V1.4.1:2005 specify?

SIST ES 201 915-11 V1.4.1:2005 is a maintenance update of ES 201 915-11 v1.3.1 and is also known as Parlay 3.3. The scope says that only the parts needing modification are updated, while most of the content is maintained with fixes.

The document is organized as a Stage 3 API specification for the Account Management Service Capability Feature (SCF). It covers the service from the use-case level down to interface details: sequence diagrams, class diagrams, service interface specifications, state transition diagrams, data definitions, and the OMG IDL description.

Annex	What it covers
Annex A (normative)	OMG IDL description of the Account Management SCF
Annex B (informative)	Contents of 3GPP OSA R4 Account Management
Annex C (informative)	Record of changes across versions

What are the key requirements of SIST ES 201 915-11 V1.4.1:2005?

SIST ES 201 915-11 V1.4.1:2005 defines how an Account Management SCF must expose account-related functions through OSA interfaces. In practice, this tells an implementer which methods, callback patterns, states and data types the service must support.

• Clause 4.1 - method support rules. If an implementation supports a method, it shall support the documented functionality for at least one valid parameter set. If a service interface method is not supported, it shall return P_METHOD_NOT_SUPPORTED. For application interfaces, a call to an unsupported method must still be possible and no exception is returned. This matters because service-side behavior and application-side callback behavior are not treated the same way.

• Clause 7.1 - interface and method conventions. The API uses UML to define interfaces, methods and parameters. Asynchronous methods use Req for requests and Res or Err for responses and error callbacks. This helps developers match each request with the right callback implementation.

• Clause 7.4 - callback setup.IpService provides setCallback() and setCallbackWithSessionID() to register the application callback interface, with the session-ID form reserved for interfaces that use session IDs. This is the connection point between service and application code.

• Clause 8.1 - IpAccountManager functions. The service-side interface covers notification control, balance queries and transaction-history retrieval. The document says an Account Management SCF shall implement queryBalanceReq(), retrieveTransactionHistoryReq(), or both createNotification() and destroyNotification() as a minimum. This is the core capability set a buyer or integrator will check.

• Clause 8.1 - request methods and identifiers.createNotification() enables charging-event notifications and returns an assignment ID. destroyNotification() disables them, changeNotification() updates the event criteria, getNotification() returns the current criteria, queryBalanceReq() starts a balance query, and retrieveTransactionHistoryReq() starts a transaction-history retrieval. The IDs let the application match later results to the original request.

• Clause 8.2 - application callbacks.IpAppAccountManager handles reportNotification(), queryBalanceRes(), queryBalanceErr(), retrieveTransactionHistoryRes() and retrieveTransactionHistoryErr(). These callbacks carry the event data, balances, query status and transaction history back to the application.

• Clause 9 and clause 10 - state and service properties. The service has an active state and a notifications-created state. Clause 10 adds capability and policy properties such as supported event types, address plan, triggering addresses, allowed currencies, allowed history interval and whether bulk balance queries are permitted. These properties matter when you need to know what the deployed service will actually accept.

What terms does SIST ES 201 915-11 V1.4.1:2005 define?

• Open Service Access (OSA) is the architecture that lets applications use network functionality through standardized interfaces.
• Application Programming Interface (API) is the interface layer used by applications and services to exchange requests, results and errors.
• Service Capability Feature (SCF) is the service-specific functional block covered by this part, here Account Management.
• Unified Modelling Language (UML) is the modeling notation used for the sequence, class and state diagrams.
• OMG IDL is the interface description language used in Annex A to represent the API in a formal syntax.
• IpAccountManager is the service-side interface for account monitoring, notification control, balance queries and transaction-history retrieval.
• IpAppAccountManager is the application-side callback interface that receives notifications and query results.

Who uses SIST ES 201 915-11 V1.4.1:2005?

SIST ES 201 915-11 V1.4.1:2005 is used by people building or integrating telecom services that need account-related network access.

• Application developers use it to call balance, notification and history methods through OSA.
• Service implementers use it to build the Account Management SCF and its callback behavior.
• Client application developers implement IpAppAccountManager to receive responses and charging-event reports.
• System integrators and testers use the diagrams, states and data definitions to check request flow and callback handling.
• Telecommunications teams use it in systems where account status, charging events and subscriber history must be exposed to applications.

What changed in SIST ES 201 915-11 V1.4.1:2005 from the previous edition?

This version is a maintenance update of ES 201 915-11 v1.3.1 and is identified as Parlay 3.3. The scope says that only the parts requiring modification were updated, and Annex C records the change categories for interfaces, methods, data definitions, service properties, exceptions and other items.

One specific change called out in Annex C is that TpChargingEventCriteria had its order of elements changed to match the IDL.

Which standards are used with SIST ES 201 915-11 V1.4.1:2005?

Standard or part	What it contributes
ETSI ES 201 915-1	Provides the overview part and the shared definitions and abbreviations used by this part
ETSI ES 201 915-2	Provides common data definitions referenced but not defined in this part
ETSI ES 201 915 family	The foreword places this document in the multi-part OSA API set, alongside the Overview, Framework and other SCF parts
3GPP TS 29.198-11 V4.4.0 (Release 4)	The foreword states that this document is equivalent to that 3GPP specification

What does the SIST ES 201 915-11 V1.4.1:2005 document contain?

The document contains the sequence diagrams for transaction-history retrieval, balance query handling and notification handling. It also contains the class diagrams for application and service interfaces, including the generic IpService base interface and the IpAccountManager / IpAppAccountManager classes.

Clause 10 gives service properties that describe what the service can support and what access may be allowed under a service agreement. Clause 11 defines the data structures used by the methods, including balance information, charging-event criteria, transaction history and status codes.

Annex A provides the formal OMG IDL version of the interface specification, which is what implementers use when generating or checking interface code. Annex C gives a change record that helps readers track interface, method, data and exception changes across versions.

SLOVENSKI STANDARD
01-januar-2005
2GSUWLGRVWRSGRVWRULWYH26$±9PHVQLN]DDSOLNDFLMVNRSURJUDPLUDQMH$3,±
GHO8SUDYOMDQMHREUDþXQD6&)
Open Service Access (OSA); Application Programming Interface (API); Part 11: Account
Management SCF (Parlay 3)
Ta slovenski standard je istoveten z: ES 201 915-11 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 11: Account Management SCF
(Parlay 3)
�
2 ETSI ES 201 915-11 V1.4.1 (2003-07)

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

Tel.: [phone]  Fax: [phone]

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:
[e-mail]
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-11 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 Account Management SCF .7
4.1 General requirements on support of methods.7
5 Sequence Diagrams.7
5.1 Standard Transaction History Retrieval .7
5.2 Standard Query Handling.8
5.3 Standard Notification handling.9
6 Class Diagrams.10
7 The Service Interface Specifications.11
7.1 Interface Specification Format .11
7.1.1 Interface Class.11
7.1.2 Method descriptions.11
7.1.3 Parameter descriptions.12
7.1.4 State Model.12
7.2 Base Interface.12
7.2.1 Interface Class IpInterface .12
7.3 Service Interfaces.12
7.3.1 Overview.12
7.4 Generic Service Interface .12
7.4.1 Interface Class IpService .12
8 Account Management Interface Classes .13
8.1 Interface Class IpAccountManager .13
8.2 Interface Class IpAppAccountManager .17
9 State Transition Diagrams.19
9.1 State Transition Diagrams for IpAccountManager.19
9.1.1 Active State.19
9.1.2 Notifications created State .19
10 Account Management Service Properties .19
11 Data Definitions.20
11.1 Account Management Data Definitions .20
11.1.1 IpAppAccountManager.20
11.1.2 IpAppAccountManagerRef.20
11.1.3 IpAccountManager.20
11.1.4 IpAccountManagerRef.20
11.1.5 TpBalanceQueryError.21
11.1.6 TpChargingEventName.21
11.1.7 TpBalanceInfo.21
11.1.8 TpChargingEventInfo.22
11.1.9 TpChargingEventCriteria.22
11.1.10 TpChargingEventNameSet.22
11.1.11 TpChargingEventCriteriaResult.22
11.1.12 TpChargingEventCriteriaResultSet.22
11.1.13 TpBalance.23
11.1.14 TpBalanceSet.23
ETSI
4 ETSI ES 201 915-11 V1.4.1 (2003-07)
11.1.15 TpTransactionHistory.23
11.1.16 TpTransactionHistorySet.23
11.1.17 TpTransactionHistoryStatus.23
12 Exception Classes.24
Annex A (normative): OMG IDL Description of Account Management SCF .25
Annex B (informative): Contents of 3GPP OSA R4 Account Management .26
Annex C (informative): Record of changes .27
C.1 Interfaces.27
C.1.1 New.27
C.1.2 Deprecated.27
C.1.3 Removed.27
C.2 Methods.27
C.2.1 New.27
C.2.2 Deprecated.27
C.2.3 Modified.28
C.2.4 Removed.28
C.3 Data Definitions.28
C.3.1 New.28
C.3.2 Modified.28
C.3.3 Removed.28
C.4 Service Properties.28
C.4.1 New.28
C.4.2 Deprecated.29
C.4.3 Modified.29
C.4.4 Removed.29
C.5 Exceptions.29
C.5.1 New.29
C.5.2 Modified.29
C.5.3 Removed.29
C.6 Others.29
History .30

ETSI
5 ETSI ES 201 915-11 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 11 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-11 V4.4.0 (Release 4).
ETSI
6 ETSI ES 201 915-11 V1.4.1 (2003-07)
1 Scope
The present document is part 11 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 Account Management Service Capability Feature (SCF) aspects of the interface. All
aspects of the Account Management 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-11 V1.4.1 (2003-07)
4 Account Management SCF
The following clauses describe each aspect of the Account Management 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 shows 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 Standard Transaction History Retrieval
: :
IpAppAccountManager IpAccountManager
1: retrieveTransactionHistoryReq( )
2: retrieveTransactionHistoryRes( )

ETSI
8 ETSI ES 201 915-11 V1.4.1 (2003-07)
1: This message is used by the application to retrieve a transaction history for a certain subscriber's account.
2: This method passes the result of the transaction history retrieval request for a specific user to its callback
object.
5.2 Standard Query Handling
: IpAppAccountManager : IpAccountManager
Application is re que sting to query
AAppplpliiccaattiioon in iss r ree qquuee ssttiinngg t too qu queerryy
the balance
tthhe be baallaancncee
1: queryBalanceReq( )
2: queryBalanceRes( )
Application is reque sting to query the
balance, but there is at least one error in the
parameters that is detected by the
IpAccountManager service.
3: queryBalanceReq( )
Application is requesting to query the
balance, but a network error occurs
4: queryBalanceReq( )
5: queryBalanceErr( )
1: This message is used to query the balance of the account of one or several users.
2: This message passes the result of the balance query for one or several users to its callback object.
ETSI
9 ETSI ES 201 915-11 V1.4.1 (2003-07)
3: This scenario shows the case where at least one error in the parameters of the message is detected by the
IpAccountManager object. An exception will be thrown.
4: This scenario shows the case where a network error occurs.
5: This message passes the error of the balance query. No exception is thrown.
5.3 Standard Notification handling
: IpAppAccountManager : IpAccountManager
1: c reateNo tifi cati on( )
2: reportNotification( )
3: getNotification( )
4: changeNotification( )
5: reportNotification( )
6: destroyNotification( )
1: This message is used by the application to request notifications from the IpAccountManager service on certain
criteria for one or several users.
2: This message is used by the IpAccountManager service to report a charging event that meets the criteria set in
the createNotification message.
3: The application can request the current criteria set in the IpAccountManager service by invoking the
getNotification method.
4: This message is used by the application to change the criteria initially created by createNotification, and
previously obtained by getNotification.
5: This message is used by the IpAccountManager service to report a charging event that meets the new criteria.
ETSI
10 ETSI ES 201 915-11 V1.4.1 (2003-07)
6: This method is used by the application to disable the charging notifications.
6 Class Diagrams
IpInterface
<>
IpAppAccountManager
reportNotification()
queryBalanceRes()
queryBalanceErr()
retrieveTransactionHistoryRes()
retrieveTransactionHistoryErr()
<>
<>
IpAccountManager
createNotification()
destroyNotification()
queryBalanceReq()
changeNotification()
getNotification()
retrieveTransactionHistoryReq()

Figure 1: Application Interfaces
ETSI
11 ETSI ES 201 915-11 V1.4.1 (2003-07)
IpService
setCallback()
setCallbackWithSessionID()
<>
IpAccountManager
(from am)
createNotification()
destroyNotification()
queryBalanceReq()
changeNotification()
getNotification()
retrieveTransactionHistoryReq()

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.
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.
ETSI
---------------
...