ETSI ES 202 915-1 V1.2.1 (2003-08)

SLOVENSKI STANDARD
01-januar-2005
Odprti dostop do storitve (OSA) – Vmesnik za aplikacijsko programiranje (API) – 1.
del: Pregled
Open Service Access (OSA); Application Programming Interface (API); Part 1: Overview
(Parlay 4)
Ta slovenski standard je istoveten z: ES 202 915-1 Version 1.2.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 1: Overview
(Parlay 4)
2 ETSI ES 202 915-1 V1.2.1 (2003-08)

Reference
RES/SPAN-120096-1
Keywords
API, IDL, OSA, 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 202 915-1 V1.2.1 (2003-08)
Contents
Intellectual Property Rights.5
Foreword.5
1 Scope.6
2 References.6
3 Definitions and abbreviations.8
3.1 Definitions.8
3.2 Abbreviations.9
4 Open Service Access APIs.10
5 Document structure.11
6 Methodology.12
6.1 Tools and Languages.12
6.2 Packaging Structure.12
6.3 Colours.15
6.4 Naming scheme.15
6.5 State Transition Diagram text and text symbols.15
6.6 Exception handling and passing results.16
6.7 References.16
6.8 Strings and Collections.16
6.9 Prefixes.16
7 Introduction to Parlay/OSA APIs.16
7.1 Interface Types.16
7.2 Service Factory.17
7.3 Use of Sessions.17
7.4 Interfaces and Sessions.17
7.5 Callback Interfaces.17
7.6 Setting Callbacks.17
7.7 Synchronous versus Asynchronous Methods .17
7.8 Out Parameters.18
7.9 Exception Hierarchy.18
7.10 Common Exceptions.18
7.11 Use of NULL.19
7.12 Notification Handling.19
8 Relationship between ETSI, Parlay and 3GPP OSA releases .20
Annex A (normative): OMG IDL .21
A.1 Tools and languages .21
A.2 Namespace.21
A.3 Object References.21
A.4 Mapping of Datatypes .21
A.4.1 Basic Datatypes.21
A.4.2 Constants.21
A.4.3 Collections.21
A.4.4 Sequences.22
A.4.5 Enumerations.22
A.4.6 Choices.22
A.5 Use of NULL.22
A.6 Exceptions.23
ETSI
4 ETSI ES 202 915-1 V1.2.1 (2003-08)
A.7 Naming space across CORBA modules.23
Annex B (informative): W3C WSDL.24
B.1 Tools and Languages.24
B.2 Proposed Namespaces for the OSA WSDL .24
B.3 Object References.25
B.4 Mapping UML Data Types to XML Schema.26
B.4.1 Data Types.26
B.4.1.1 <>.26
B.4.1.2 <>.26
B.4.1.3 <>.26
B.4.1.4 <>.27
B.4.1.5 <>.27
B.4.1.6 <>.27
B.5 Mapping of UML SCF to WSDL.28
B.5.1 Mapping of Operations to WSDL message element .28
B.5.2 Mapping of Exception to WSDL message element.28
B.5.3 Mapping of CommonExceptions to WSDL message element .29
B.5.4 Mapping of Interface Class to WSDL portType and binding elements.29
B.5.5 Mapping of UML SCF to WSDL service element .30
Annex C (informative): Java API .31
C.1 Tools and Languages.31
C.2 JAIN SPA Overview .31
Annex D (informative): Bibliography.32
History .33

ETSI
5 ETSI ES 202 915-1 V1.2.1 (2003-08)
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 1 of a multi-part deliverable covering Open Service Access (OSA); Application
Programming Interface (API), as identified below. The API specification (ES 202 915) is structured in the following
parts:
Part 1: "Overview";
Part 2: "Common Data Definitions";
Part 3: "Framework";
Part 4: "Call Control";
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";
Part 13: "Policy management SCF";
Part 14: "Presence and Availability Management 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 4.1 set of specifications.
The present document is equivalent to 3GPP TS 29.198-1 V5.2.0 (Release 5).
ETSI
6 ETSI ES 202 915-1 V1.2.1 (2003-08)
1 Scope
The present document is the part 1 of the Stage 3 specification for an Application Programming Interface for Open
Service Access (OSA), and provides an overview of the content and structure of the various parts of the present
document, and of the relation to other standards documents.
The OSA specifications define an architecture that enables service application developers to make use of network
functionality through an open standardized interface, i.e. the OSA APIs.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
[1] ETSI TR 121 905: "Universal Mobile Telecommunications System (UMTS); Vocabulary for
3GPP Specifications (3GPP TR 21.905)".
[2] ETSI TS 122 024: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); Description of Charge Advice Information (CAI)
(3GPP TS 22.024)".
[3] ITU-T Recommendation Q.850: "Usage of cause and location in the Digital Subscriber Signalling
System No. 1 and the Signalling System No. 7 ISDN User Part".
[4] ITU-T Recommendation Q.2931: "Digital Subscriber Signalling System No. 2 - User-Network
Interface (UNI) layer 3 specification for basic call/connection control".
[5] ETSI TS 122 101: "Universal Mobile Telecommunications System (UMTS); Service aspects;
Service principles (3GPP TS 22.101)".
[6] World Wide Web Consortium: "Composite Capability/Preference Profiles (CC/PP): A user side
framework for content negotiation". (http://www.w3.org/TR/NOTE-CCPP/).
[7] ETSI TS 129 002: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); Mobile Application Part (MAP) specification
(3GPP TS 29.002)".
[8] ETSI TS 129 078: "Universal Mobile Telecommunications System (UMTS); Digital cellular
telecommunications system (Phase 2+); Customised Applications for Mobile network Enhanced
Logic (CAMEL) Phase 3; CAMEL Application Part (CAP) specification (3GPP TS 29.078)".
[9] Wireless Application Protocol (WAP), Version 2.0: "User Agent Profiling Specification"
(WAP-248). (http://www.wapforum.org/what/technical.htm).
[10] ETSI TS 122 002: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); Circuit Bearer Services (BS) supported by a Public
Land Mobile Network (PLMN) (3GPP TS 22.002)".
[11] ETSI TS 122 003: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); Circuit Teleservices supported by a Public Land
Mobile Network (PLMN) (3GPP TS 22.003)".
ETSI
7 ETSI ES 202 915-1 V1.2.1 (2003-08)
[12] ETSI TS 124 002: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); GSM - UMTS Public Land Mobile Network
(PLMN) access reference configuration (3GPP TS 24.002)".
[13] ITU-T Recommendation Q.763: "Signalling System No. 7 - ISDN User Part formats and codes".
[14] ITU-T Recommendation Q.931: "ISDN user-network interface layer 3 specification for basic call
control".
[15] ISO 8601: "Data elements and interchange formats - Information interchange - Representation of
dates and times".
[16] ISO 4217: "Codes for the representation of currencies and funds".
[17] ISO 639: "Code for the representation of names of languages".
[18] IETF RFC 822: "Standard for the format of ARPA Internet text messages".
[19] IETF RFC 1738: "Uniform Resource Locators (URL)".
[20] ETSI TS 129 198 (V3.4.0): "Universal Mobile Telecommunications System (UMTS); Open
Service Architecture (OSA) Application Programming Interface (API) - Part 1 (3GPP TS 29.198
version 3.4.0 Release 1999)".
[21] ETSI TS 129 198 (all parts): "Universal Mobile Telecommunications System (UMTS); Open
Service Access (OSA) Application Programming Interface (API); (3GPP TS 29.198 Release 5)".
[22] ETSI TS 123 107: "Universal Mobile Telecommunications System (UMTS); Quality of Service
(QoS) concept and architecture" (3GPP TS 23.107)".
[23] ETSI TS 123 271: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); Functional stage 2 description of location services
(3GPP TS 23.271)".
[24] ANSI T1.113: "Signalling System No. 7 (SS7) - Integrated Services Digital Network (ISDN) User
Part (ISUP)".
[25] IETF RFC 3261: "SIP: Session Initiation Protocol".
[26] ITU-T Recommendation Q.932: "Digital subscriber signalling system No. 1 - Generic procedures
for the control of ISDN supplementary services".
[27] ITU-T Recommendation H.221: "Frame structure for a 64 to 1920 kbit/s channel in audiovisual
teleservices".
[28] ITU-T Recommendation H.323: "Packet-based multimedia communications systems".
[29] IETF RFC 1994: "PPP Challenge Handshake Authentication Protocol (CHAP)".
[30] IETF RFC 2630: "Cryptographic Message Syntax".
[31] IETF RFC 2313: "PKCS #1: RSA Encryption Version 1.5".
[32] IETF RFC 2459: "Internet X.509 Public Key Infrastructure Certificate and CRL Profile".
[33] IETF RFC 2437: "PKCS #1: RSA Cryptography Specifications Version 2.0".
[34] IETF RFC 1321: "The MD5 Message-Digest Algorithm".
[35] IETF RFC 2404: "The Use of HMAC-SHA-1-96 within ESP and AH".
[36] IETF RFC 2403: "The Use of HMAC-MD5-96 within ESP and AH".
[37] ITU-T Recommendation G.722: "7 kHz audio-coding within 64 kbit/s".
[38] ITU-T Recommendation G.711: "Pulse code modulation (PCM) of voice frequencies".
ETSI
8 ETSI ES 202 915-1 V1.2.1 (2003-08)
[39] ITU-T Recommendation G.723.1: "Speech coders: Dual rate speech coder for multimedia
communications transmitting at 5.3 and 6.3 kbit/s".
[40] ITU-T Recommendation G.728: "Coding of speech at 16 kbit/s using low-delay code excited
linear prediction".
[41] ITU-T Recommendation G.729: "Coding of speech at 8 kbit/s using conjugate-structure algebraic-
code-excited linear-prediction (CS-ACELP)".
[42] ITU-T Recommendation H.261: "Video codec for audiovisual services at p x 64 kbit/s".
[43] ITU-T Recommendation H.263: "Video coding for low bit rate communication".
[44] ITU-T Recommendation H.262: "Information technology - Generic coding of moving pictures and
associated audio information: Video".
[45] World Geodetic System 1984 (WGS 84). (http://www.wgs84.com/files/wgsman24.pdf).
[46] ITU-T Recommendation X.400: "Message handling services: Message handling system and
service overview".
[47] ITU-T Recommendation E.164: "The international public telecommunication numbering plan".
[48] IETF RFC 2445: "Internet Calendaring and Scheduling Core Object Specification (iCalendar)".
[49] IETF RFC 2778: "A Model for Presence and Instant Messaging".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in TS 122 101 [5] and the following apply:
applications: services, which are designed using service capability features
gateway: synonym for Service Capability Server
NOTE: From the viewpoint of applications, a Service Capability Server can be seen as a gateway to the core
network.
HE-VASP: Home Environment Value Added Service Provider
NOTE: This is a VASP that has an agreement with the Home Environment to provide services.
Home Environment: responsible for overall provision of services to users
Local Service: service which can be exclusively provided in the current serving network by a Value Added Service
Provider
OSA Interface: standardized Interface used by application to access service capability features
Personal Service Environment (PSE): contains personalized information defining how subscribed services are
provided and presented towards the user
NOTE: The Personal Service Environment is defined in terms of one or more User Profiles.
Service Capabilities (SC): bearers defined by parameters, and/or mechanisms needed to realize services
NOTE: These are within networks and under network control.
Service Capability Feature (SCF): functionality offered by service capabilities that are accessible via the standardized
OSA interface
Service Capability Server: Functional Entity providing OSA interfaces towards an application
ETSI
9 ETSI ES 202 915-1 V1.2.1 (2003-08)
Service: alternative for Service Capability Feature (in ES 202 915-1)
User Interface Profile: contains information to present the personalized user interface within the capabilities of the
terminal and serving network
User Profile: label identifying a combination of one user interface profile, and one user services profile
User Services Profile: contains identification of subscriber services, their status and reference to service preferences
Value Added Service Provider: provides services other than basic telecommunications service for which additional
charges may be incurred
Virtual Home Environment: concept for personal service environment portability across network boundaries and
between terminals
3.2 Abbreviations
For the purposes of the present document, the abbreviations defined in TR 121 905 [1] and the following apply:
API Application Programming Interface
CAMEL Customized Application for Mobile Network Enhanced Logic
CGI Cell Global Identification
CI Cell Identification
CSE Camel Service Environment
GPS Global Positioning System
HE Home Environment
HE-VASP Home Environment Value Added Service Provider
HPLMN Home Public Land Mobile Network
IDL Interface Description Language
JSR Java Specification Request
IMEI International Mobile station Equipment Identity
LAC Location Area Code
MAP Mobile Application Part
MCC Mobile Country Code
MExE Mobile Station (Application) Execution Environment
MNC Mobile Network Code
MS Mobile Station
MSC Mobile Switching Centre
NA-ESRD North American Emergency Services Routing Digits
NA-ESRK North American Emergency Services Routing Key
LAI Location Area Identification
LCS Location Services
OSA Open Service Access
PLMN Public Land Mobile Network
PSE Personal Service Environment
QoS Quality of Service
RMI Java Remote Method Invocation
SAG Subscription Assignment Group
SC Service Capabilities
SCF Service Capability Feature
SCS Service Capability Server
STD State Transition Diagrams
SIM Subscriber Identity Module
SMS Short Message Service
SMTP Simple Mail Transfer Protocol
SOAP Simple Object Access Protocol
SPA Service Provider API
USSD Unstructured Supplementary Service Data
VASP Value Added Service Provider
VLR Visited Location Register
VPLMN Visited Public Land Mobile Network
WAP Wireless Application Protocol
ETSI
10 ETSI ES 202 915-1 V1.2.1 (2003-08)
WSDL Web Services Definition Language
XML Extensible Markup Language
4 Open Service Access APIs
The OSA specifications define an architecture that enables service application developers to make use of network
functionality through an open standardized interface, i.e. the OSA APIs. The network functionality is describes as
Service Capability Features or Services (see note). The OSA Framework is a general component in support of Services
(Service Capabilities) and Applications.
The OSA API is split into three types of interface classes, Service and Framework.
• Interface classes between the Applications and the Framework, that provide applications with basic
mechanisms (e.g. Authentication) that enable them to make use of the service capabilities in the network.
• Interface classes between Applications and Service Capability Features (SCF), which are individual services
that may be required by the client to enable the running of third party applications over the interface
e.g. Messaging type service.
• Interface classes between the Framework and the Service Capability Features, that provide the mechanisms
necessary for multi-vendorship.
• Interface classes between the Enterprise Operator and the Framework that provides the Enterprise Operator
with basic mechanisms to allow them to administer client application accounts and to manage their service
contracts and profiles.
These interfaces represent interfaces 1, 2, 3 and 4 of the figure 1. The other interfaces are not yet part of the scope of the
work.
Enterprise
operator
admin tool
Not in
scope
of this API
version
Client
Application
Not in scope of
Not in scope of
this version of
this version of
the API
Not in scope of the API
Not in scope of
4 1 2 6
4 1 2 6
this version of
this version of
the API
the API
Service
supplier
Framework
admin tool
operator
admin
Telecom Network
Figure 1
ETSI
11 ETSI ES 202 915-1 V1.2.1 (2003-08)
Within the OSA concept a set of Service Capability Features has been specified. The OSA documentation is structured
in parts. The first Part (the present document) contains an overview, the second Part contains common Data Definitions,
the third Part the Framework interfaces. The rest of the Parts contain the description of the SCFs.
NOTE: The terms "Service" and "Service Capability Feature" are used as alternatives for the same concept in the
present document. In the OSA API itself the Service Capability Features as identified in the 3GPP
requirements and architecture are reflected as 'service', in terms like service instance lifecycle manager,
serviceDiscovery.
5 Document structure
The Parts of the present document ES 202 915 (apart from 1 (the present document) and 2) define the interfaces,
parameters and state models that form part of the API specification. UML is used to specify the interface classes. As
such it provides a UML interface class description of the methods (API calls) supported by that interface and the
relevant parameters and types. The interfaces are specified both in IDL and in WSDL. Reference is made to the Java
API specification of the interfaces.
The purpose of the OSA API is to shield the complexity of the network, its protocols and specific implementation from
the applications. This means that applications do not have to be aware of the network nodes a Service Capability Server
interacts with in order to provide the Service Capability Features to the application. The specific underlying network
and its protocols are transparent to the application.
The API specification ES 202 915 is structured in the following parts:
Part 1: "Overview";
Part 2: "Common Data Definitions";
Part 3: "Framework";
Part 4: "Call Control";
Sub-part 1: "Call Control Common Definitions";
Sub-part 2: "Generic Call Control SCF";
Sub-part 3: "Multi-Party Call Control SCF";
Sub-part 4: "Multi-Media Call Control SCF";
Sub-part 5: "Conference 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";
Part 13: "Policy Management SCF";
Part 14: "Presence and Availability Management SCF".
ETSI
12 ETSI ES 202 915-1 V1.2.1 (2003-08)
A 3GPP mapping document, TR 129 998, is also structured according to the same parts. It contains a possible mapping
from some of the APIs defined in ES 202 915 to various network protocols (i.e. MAP [7], CAP [8], etc.). It is an
informative document, since this mapping is considered as implementation/vendor dependent. On the other hand this
mapping will provide potential service designers with a better understanding of the relationship of the OSA API
interface classes and the behaviour of the network associated to these interface classes. A mapping to network
protocols is not applicable for all parts, but the numbering of parts is kept. Also in case a part is not supported in a
Release, the numbering of the parts is maintained.
Structure of the Parts of ES 202 915:
The Parts with API specification themselves are structured as follows:
• The Sequence diagrams give the reader a practical idea of how each of the service capability feature 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 progression of internal processes either in the application, or
Gateway.
• 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.
The OSA API is defined using UML and as such is technology independent. OSA can be realised in a number of ways
and in addition to the UML defined OSA API, the OSA specification includes:
• A normative annex with the OSA API in IDL that specifies the CORBA distribution technology realisation.
• An informative annex with the OSA API in WSDL that specifies the SOAP/HTTP distribution technology
realisation.
• An informative annex that references the OSA API in Java (known as JAIN™ Service Provider API) that
specifies the Java local API technology realisation.
6 Methodology
Following is a description of the methodology used for the establishment of API specification for OSA.
6.1 Tools and Languages
The Unified Modelling Language (UML) (http://www.omg.org/uml/) is used as the means to specify class and state
transition diagrams.
6.2 Packaging Structure
A hierarchical packaging scheme is used to avoid polluting the global name space. The root is defined as:
org.csapi
The following diagram shows the packaging hierarchy. The root package is shown on the left most side of the figure.
Extending from the root package are the framework and services branch packages, then the associated leaf packages.
Listed against each package are the interfaces, data types, exceptions and service properties it contains.
ETSI
13 ETSI ES 202 915-1 V1.2.1 (2003-08)
Packaging Hierarchy Contains
org.csapi    IpInterface
IpService
All common data types
All common exceptions
All common service properties
.fw   Common Framework data types
Common Framework exceptions
Common Framework service
properties
.access
.trust_and_security Package interfaces
Package data types
Package exceptions
Package service properties
.application
.notification Package interfaces
Package data types
Package exceptions
Package service properties
.integrity Package interfaces
Package data types
Package exceptions
Package service properties
.service_agreement Package interfaces
Package data types
Package exceptions
Package service properties
.discovery Package interfaces
Package data types
Package exceptions
Package service properties
.enterprise_operator
.service_subscription Package interfaces
Package data types
Package exceptions
Package service properties
service
.notification Package interfaces
Package data types
Package exceptions
Package service properties
.integrity Package interfaces
Package data types
Package exceptions
Package service properties
.discovery Package interfaces
Package data types
Package exceptions
Package service properties
.service_lifecycle Package interfaces
Package data types
Package exceptions
Package service properties
.service_registration Package interfaces
Package data types
Package exceptions
Package service properties
.services   Common Service data types
Common Service exceptions
Common Service service
properties
.cc  Common Call Control data types
Common Call Control exceptions
Common Call Control service
properties
ETSI
14 ETSI ES 202 915-1 V1.2.1 (2003-08)
Packaging Hierarchy Contains
.gccs Package interfaces
Package data types
Package exceptions
Package service properties
.mpccs Package interfaces
Package data types
Package exceptions
Package service properties
.mmccs Package interfaces
Package data types
Package exceptions
Package service properties
.cccs Package interfaces
Package data types
Package exceptions
Package service properties
.ui  Package interfaces
Package data types
Package exceptions
Package service properties
.mm  Common Mobility management
data types
Common Mobility management
exceptions
Common Mobility management
service properties
.ul Package interfaces
Package data types
Package exceptions
Package service properties
.ulc Package interfaces
Package data types
Package exceptions
Package service properties
.ule Package interfaces
Package data types
Package exceptions
Package service properties
.us Package interfaces
Package data types
Package exceptions
Package service properties
.termcap  Package interfaces
Package data types
Package exceptions
Package service properties
.dsc  Package interfaces
Package data types
Package exceptions
Package service properties
.gms  Package interfaces
Package data types
Package exceptions
Package service properties
.cm  Package interfaces
Package data types
Package exceptions
Package service properties
.am  Package interfaces
Package data types
Package exceptions
Package service properties
.cs  Package interfaces
Package data types
Package exceptions
Package service properties
ETSI
15 ETSI ES 202 915-1 V1.2.1 (2003-08)
NOTE 1: Not all the packages given above may be found in the 3GPP OSA specifications.
NOTE 2: Where data types, exceptions and service properties are indicated in the figure above their presence, or
otherwise, is dependent upon the package in question. For example, if there are no common Framework
exceptions then none will be present in the org.csapi.fw package.
6.3 Colours
For clarity, class diagrams follow a certain colour scheme. Blue for application interface packages and yellow for all the
others.
6.4 Naming scheme
The following naming scheme is used for documentation.
packages:
lowercase
Using the domain-based naming (For example, org.csapi)
classes, structures and types. Start with T:
TpCapitalizedWithInternalWordsAlsoCapitalized
Exception class:
TpClassNameEndsWithException and
P_UPPER_CASE_WITH_UNDERSCORES_AND_START_WITH_P
Interface. Start with Ip:
IpThisIsAnInterface
constants:
P_UPPER_CASE_WITH_UNDERSCORES_AND_START_WITH_P
methods:
firstWordLowerCaseButInternalWordsCapitalized()
method's parameters:
firstWordLowerCaseButInternalWordsCapitalized
collections (set, array or list types):
TpCollectionEndsWithSet
class/structure members:
FirstWordAndInternalWordsCapitalized
Spaces in between words are not allowed.
6.5 State Transition Diagram text and text symbols
The descriptions of the State Transitions in the State Transition Diagrams follow the convention:
when_this_event_is_received [guard condition is true] /do_this_action ^send_this_message
Furthermore, text underneath a line through the middle of a State indicates an exit or entry event (normally specified
which one).
ETSI
16 ETSI ES 202 915-1 V1.2.1 (2003-08)
6.6 Exception handling and passing results
OSA methods communicate errors in the form of exceptions. OSA methods themselves always use the return parameter
to pass results. If no results are to be returned a void is used instead of the return parameter. In order to support mapping
to as many languages as possible, no method out parameters are allowed.
6.7 References
In the interface specification whenever Interface parameters are to be passed as an in parameter, they are done so by
reference, and the "Ref" suffix is appended to their corresponding type (e.g. IpAnInterfaceRef anInterface), a reference
can also be viewed as a logical indirection.
Original type IN parameter declaration
IpInterface parm : IN IpInterfaceRef

6.8 Strings and Collections
For character strings, the String data type is used without regard to the maximum length of the string. For homogeneous
collections of instances of a particular data type the following naming scheme is used: Set.
6.9 Prefixes
OSA constants and data types are defined in the global name space: org.csapi module.
7 Introduction to Parlay/OSA APIs
This clause contains the general rules that were followed by the design of the Parlay/OSA APIs and advice for how to
use them. Note however that exceptions to these "rules" may exist and that examples are not exhaustive.
7.1 Interface Types
In the Parlay/OSA specifications different types of interfaces are distinguished:
• Application side (callback) interfaces. This type of interface needs to be implemented by an application
(client) and the name of such an interface is prefixed with "IpApp".
• Interfaces of an SCF that are used by the Framework. The name of this type of server interface is prefixed with
"IpSvc".
• Application side interfaces and SCF interfaces that are shared. The name of this type of interface is prefixed
with "IpClient".
• Interfaces of the Framework that are used by an SCF. The name of this type of server interface is prefixed with
"IpFw".
The name of all other interfaces of the Framework and SCFs that are used by an application, is prefixed with "Ip".
ETSI
17 ETSI ES 202 915-1 V1.2.1 (2003-08)
7.2 Service Factory
For each application that uses an SCF, a separate object is created to handle all communication to the application. This
object is referred to as the Service Manager. The pattern used is often referred to as the Factory Pattern. The Service
Manager creates any new objects in the SCF. The Service Manager and all the objects created by it are referred to as
"service instance".
Once an application is granted access to an SCF, the Framework requests the SCF to create a new Service Manager.
The reference to this Service Manager is provided to the application. From this moment onwards the application can
start using the SCF.
7.3 Use of Sessions
A session is a series of interactions between two communication end points that occur during the span of a single
connection. An example is all operations to set-up, control, and tear down a (multi-party) call. A session is identified by
a Session ID. This ID is unique within the scope of a service instance and can be related to session numbers used in the
network.
7.4 Interfaces and Sessions
Some interfaces have a one-to-one relation with a session. For every session there is a separate interface instance. In this
case, this instance of an interface represents the session. All methods invoked on such an interface operate on the same
session. These interfaces make no use of Session IDs.
Other interfaces can represent multiple sessions. The underlying implementation can then either create an instance per
session or it can handle multiple sessions per instance (e.g. to combat extensive resource usage). When a method on
such an interface is invoked it requires a Session ID to uniquely identify the session to which it applies.
7.5 Callback Interfaces
Some Parlay/OSA int
...