ETSI TS 123 198 V7.3.0 (2008-01)

Technical Specification
Universal Mobile Telecommunications System (UMTS);
Open Service Access (OSA);
Stage 2
(3GPP TS 23.198 version 7.3.0 Release 7)

3GPP TS 23.198 version 7.3.0 Release 7 1 ETSI TS 123 198 V7.3.0 (2008-01)

Reference
RTS/TSGC-0523198v730
Keywords
UMTS
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, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
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 2008.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
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
3GPP TS 23.198 version 7.3.0 Release 7 2 ETSI TS 123 198 V7.3.0 (2008-01)
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 Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables.
The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under
http://webapp.etsi.org/key/queryform.asp.
ETSI
3GPP TS 23.198 version 7.3.0 Release 7 3 ETSI TS 123 198 V7.3.0 (2008-01)
Contents
Intellectual Property Rights.2
Foreword.2
Foreword.5
Introduction .5
1 Scope.7
2 References.7
3 Definitions and abbreviations.7
3.1 Definitions.7
3.2 Abbreviations.8
4 OSA support of VASP .8
5 Open Service Access.9
5.1 Overview of the Open Service Access .9
5.2 Basic mechanisms in the Open Service Access.13
5.3 Service Brokering.14
6 Framework.15
6.1 Trust and Security Management Functions .15
6.1.1 Initial Contact.15
6.1.2 Authentication.15
6.1.3 OSA Access.15
6.2 Discovery.16
6.3 Integrity Management functions.16
6.3.1 Load Manager.16
6.3.2 Fault Manager.16
6.3.3 Heartbeat Management.16
6.3.4 OAM.16
6.4 Registration of SCFs with the Framework .17
6.4.1 Service Registration.17
6.4.2 Service Factory.17
7 Service Capability Features (SCFs) .18
7.1 Call Control.18
7.1.1 Mapping of OSA APIs in CS domain .18
7.1.2 Mapping of OSA APIs in IMS .18
7.2 Data Session Control.20
7.3 Mobility.20
7.4 Terminal Capabilities .21
7.5 User Interaction.21
7.6 Charging.21
7.7 Account Management.21
7.8 Presence.22
7.8.1 Mapping of OSA Presence APIs.22
7.9 Multi Media Messaging (MMM) .23
7.9.1 Mapping of OSA MM APIs.23
7.10 Policy Management.23
8 Parlay X Web Services: OSA at a higher level of abstraction .24
8.1 General.24
8.1.1 Deployment Scenario A: Web Services to OSA.26
8.1.2 Deployment Scenario B: Web Services to Network Element.26
8.2 Third Party Call.27
8.3 Network-Initiated Third Party Call .27
8.4 SMS.27
ETSI
3GPP TS 23.198 version 7.3.0 Release 7 4 ETSI TS 123 198 V7.3.0 (2008-01)
8.5 Multimedia Message.28
8.6 Payment.28
8.7 Account Management.28
8.8 Terminal Status .29
8.9 Terminal Location.29
8.10 Audio Call.29
8.11 Call Handling.29
8.12 Multimedia Conferencing.30
8.13 Address List Management.30
8.14 Presence.30
8.15 Message Broadcast.30
8.16 Geocoding.31
8.17 Application Driven QoS.31
8.18 Device Management.31
8.19 Multimedia Streaming Control.31
8.20 Multimedia Multicast Session Management .31
Annex A (informative): Change History .33
History .34

ETSI
3GPP TS 23.198 version 7.3.0 Release 7 5 ETSI TS 123 198 V7.3.0 (2008-01)
Foreword
rd
This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
Introduction
The Open Service Access (OSA) defines an architecture that enables service application developers to make use of
network functionality through open standardized interface, i.e. the OSA APIs and Parlay X Web Services. The network
functionality is describes as Service Capability Features (SCFs) or Services. The OSA Framework is a general
component in support of Services (Service Capabilities) and Applications. The concepts and the functional architecture
for the OSA are contained in the present document. The requirements for OSA are contained in 3GPP TS 22.127 [3].
NOTE: The terms "Service" and "Service Capability Feature" are used as alternatives for the same concept in the
present document. In the OSA Application Programming Interface (API) itself, the SCFs as identified in
the 3GPP requirements and architecture are reflected as "service", in terms like service instance lifecycle
manager, service Discovery.
The present document is part of a TS-family as identified below:
22.127: "Service Requirement for the Open Services Access (OSA); Stage 1".
23.198: "Open Service Access (OSA); Stage 2".
Stage 3 Technical Specifications (TSs):
29.198-01: "OSA API; Part 1: Overview".
29.198-02: "OSA API; Part 2: Common data".
29.198-03: "OSA API; Part 3: Framework".
29.198-04: "OSA API; Part 4: Call control".
29.198-04-1: "OSA API; Part 4: Call control; Subpart 1: Common call control data definitions".
29.198-04-2: "OSA API; Part 4: Call control; Subpart 2: Generic call control data SCF".
29.198-04-3: "OSA API; Part 4: Call control; Subpart 3: Multi-party call control data SCF".
29.198-04-4: "OSA API; Part 4: Call control; Subpart 4: Multimedia call control SCF".
29.198-04-5: "OSA API; Part 4: Call control; Subpart 5: Conference call control SCF".
29.198-05: "OSA API; Part 5: Generic user interaction".
29.198-06: "OSA API; Part 6: Mobility".
29.198-07: "OSA API; Part 7: Terminal capabilities".
29.198-08: "OSA API; Part 8: Data session control".
29.198-09: does not exist
29.198-10: does not exist
29.198-11: "OSA API; Part 11: Account management".
ETSI
3GPP TS 23.198 version 7.3.0 Release 7 6 ETSI TS 123 198 V7.3.0 (2008-01)
29.198-12: "OSA API; Part 12: Charging".
29.198-13: "OSA API; Part 13: Policy management SCF".
29.198-14: "OSA API; Part 14: Presence and Availability Management (PAM)".
29.198-15: "OSA API; Part 15: Multi-media Messaging (MM) SCF".
29.198-16: "OSA API; Part 16: Service Broker Service Capability Feature (SCF)".

29.199-01: "OSA; Parlay X web services; Part 1: Common".
29.199-02: "OSA; Parlay X web services; Part 2: Third party call".
29.199-03: "OSA; Parlay X web services; Part 3: Call notification".
29.199-04: "OSA; Parlay X web services; Part 4: Short messaging".
29.199-05: "OSA; Parlay X web services; Part 5: Multimedia messaging".
29.199-06: "OSA; Parlay X web services; Part 6: Payment".
29.199-07: "OSA; Parlay X web services; Part 7: Account management".
29.199-08: "OSA; Parlay X web services; Part 8: Terminal status".
29.199-09: "OSA; Parlay X web services; Part 9: Terminal location".
29.199-10: "OSA; Parlay X web services; Part 10: Call handling".
29.199-11: "OSA; Parlay X web services; Part 11: Audio call".
29.199-12: "OSA; Parlay X web services; Part 12: Multimedia conference".
29.199-13: "OSA; Parlay X web services; Part 13: Address list management".
29.199-14: "OSA; Parlay X web services; Part 14: Presence".
29.199-15: "OSA; Parlay X web services; Part 15: Message Broadcast".
29.199-16: "OSA; Parlay X web services; Part 16: Geocoding".
29.199-17: "OSA; Parlay X web services; Part 17: Application driven Quality of Service (QoS)".
29.199-18: "OSA; Parlay X web services; Part 18: Device management".
29.199-19: "OSA; Parlay X web services; Part 19: Multimedia streaming control".
29.199-20: "OSA; Parlay X web services; Part 20: Multimedia multicast session management".

Technical Reports (TRs):
29.998-01: "OSA API Mapping for OSA; Part 1: General issues on API mapping".
29.998-04-1: "OSA API Mapping for OSA; Part 4: Call Control Service Mapping; Subpart 1: API to CAP
Mapping".
29.998-04-2: "OSA API Mapping for OSA; Part 4: Call Control Service Mapping; Subpart 2: INAP".
29.998-04-3: "OSA API Mapping for OSA; Part 4: Call Control Service Mapping; Subpart 3: MEGACO
mapping".
29.998-04-4: "OSA API Mapping for OSA; Part 4: Call Control Service Mapping; Subpart 4: Multiparty Call
Control ISC".
29.998-05-1: "OSA API Mapping for OSA; Part 5: User Interaction Service Mapping; Subpart 1: API to CAP
Mapping".
29.998-05-2: "OSA API Mapping for OSA; Part 5: User Interaction Service Mapping; Subpart 2: INAP
mapping".
29.998-05-3: "OSA API Mapping for OSA; Part 5: User Interaction Service Mapping; Subpart 3: MEGACO
mapping".
29.998-05-4: "OSA API Mapping for OSA; Part 5: User Interaction Service Mapping; Subpart 4: API to SMS
Mapping".
29.998-06-1: "OSA API Mapping for OSA; Part 6: User Location - User Status Service Mapping; Subpart 1:
Mapping to MAP".
29.998-06-2: "OSA API Mapping for OSA; Part 6: User Location - User Status Service Mapping; Subpart 1:
Mapping to SIP".
29.998-08: "OSA API Mapping for OSA; Part 8: Data Session Control Service Mapping to CAP".
ETSI
3GPP TS 23.198 version 7.3.0 Release 7 7 ETSI TS 123 198 V7.3.0 (2008-01)
1 Scope
The present document specifies the stage 2 of the Open Service Access (OSA).
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, edition number, version number, etc.) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1] 3GPP TS 22.101: "Service aspects; Service principles".
[2] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[3] 3GPP TS 22.127: "Service Requirement for the Open Services Access (OSA); Stage 1".
[4] 3GPP TS 23.218: "IP Multimedia (IM) session handling; IM call model; Stage 2".
[5] 3GPP TS 22.141: "Presence service; Stage 1".
[6] 3GPP TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2".
[7] 3GPP TS 23.141: "Presence service; Architecture and functional description; Stage 2".
[8] 3GPP TS 23.140: "Multimedia Messaging Service (MMS); Functional description; Stage 2".
[9] 3GPP TS 23.271: "Location Services (LCS); Functional description; Stage 2".
[10] ITU-T Recommendation Q.763: "Signalling System No. 7 - ISDN User Part formats and codes".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in 3GPP TS 22.101 [1], 3GPP TR 21.905 [2]
and the following apply:
applications: software components providing services to end-users by utilizing Service Capability Features
Home Environment (HE): operator responsible for overall provision of services to users
Home Environment Value Added Service Provider: home service provider to users other than the operator
interface: listing and semantics of the methods and attributes provided by an object that belongs to a Service Capability
Feature
OSA API: standardized API used by applications to access Service Capability Features
OSA Internal API: standardized API between framework and service capability servers
Service Capabilities: See 3GPP TS 22.127 [3].
ETSI
3GPP TS 23.198 version 7.3.0 Release 7 8 ETSI TS 123 198 V7.3.0 (2008-01)
Service Capability Feature (SCF): See 3GPP TS 22.127 [3].
Service Capability Server (SCS): Functional Entity providing OSA interfaces towards an application
Value Added Service Provider: service provider to users other than the operator
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in 3GPP TS 22.101 [1], 3GPP TR 21.905 [2] and the
following apply:
API Application Programming Interface
HE Home Environment
HE-VASP Home Environment - Value Added Service Provider
HSS Home Subscriber Server
IMS IP Multimedia core network Subsystem
ISC IMS Service Control
MRF Media Resource Function
MRFC Media Resource Function Controller
MRFP Media Resource Function Protocol
OSA Open Service Access
SCF Service Capability Feature
SCS Service Capability Server
S-CSCF Serving - Call Session Control Function
SMS-C Short Message Service - Center
SOAP Simple Object Access Protocol
VASP Value Added Service Provider
4 OSA support of VASP
The OSA APIs may be used by the Home Environment, by Value Added Service Providers (VASPs) and Home
Environment Value Added Service Providers (HE-VASPs).
OSA is optimized to support HE-VASPs as the user subscription information is owned and managed by the Home
Environment, i.e. the Home Environment knows which users are subscribed to the service implemented by the OSA
application, and if the service is activated or not.
Specific methods are specified in OSA Service Capability Features, permitting:
• An OSA application to request user related event notifications pertaining to any subscribed user for which the
service implemented by the application is activated.
• The OSA SCS to report user related event notifications in which it explicitly identifies the user to which the
event applies.
• An OSA application to request a function to be applied to all current subscribed users for which the service
implemented by the application is activated.
The OSA SCS can report user related events to the OSA application, without the application having explicitly
subscribed to the event (events to be reported have been agreed between the Home Environment and the HE-VASP by
other means, e.g. in their service level agreement).
This functionality is supported by all relevant Service Capability Features, like call and session control SCFs, user
status, and user location.
ETSI
3GPP TS 23.198 version 7.3.0 Release 7 9 ETSI TS 123 198 V7.3.0 (2008-01)
5 Open Service Access
In order to be able to implement future applications/end user services that are not yet known today, a highly flexible
Framework for Services is required. The Open Service Access (OSA) enables applications implementing the services to
make use of network functionality. Network functionality offered to applications is defined in terms of a set of Service
Capability Features (SCFs). These SCFs provide functionality of network capabilities, which is accessible to
applications through the standardized OSA interface for service development.
The aim of OSA is to provide a standardized, extensible and scalable interface that allows for inclusion of new
functionality in the network in future releases with a minimum impact on the applications using the OSA interface.
Network functionality offered to applications is defined as a set of Service Capability Features (SCFs) in the OSA API,
which are supported by different Service Capability Servers (SCS). These SCFs provide access to the network
capabilities on which the application developers can rely when designing new applications (or enhancements/variants of
already existing ones). The different features of the different SCSs can be combined as appropriate.
The exact addressing (parameters, type and error values) of these features is described in stage 3 descriptions.
TM
These descriptions (defined using UML and in three realizations: OMG Interface Description Language ,
TM TM
Java J2SE and Java J2EE are open and accessible to application developers, who can design services in any
programming language, while the underlying core network functions use their specific protocols. The present document
also contains a set of Web Services called Parlay X Web Services, specified in WSDL.
The standardized OSA APIs are secure, independent of vendor specific solutions and independent of programming
languages, operating systems etc used in the service capabilities. The OSA APIs are independent of the location within
the home environment where service capabilities are implemented, and independent of supported service capabilities in
the network. Furthermore, an architecture with open interfaces allows for application developers to rapidly design new
and innovative applications.
5.1 Overview of the Open Service Access
The Open Service Access consists of three parts:
• Applications: e.g. VPN, conferencing, location based applications. These applications are implemented in one
or more Application Servers.
• Framework: providing applications with basic mechanisms that enable them to make use of the service
capabilities in the network. Examples of framework functions are Authentication, and Registration and
Discovery. Service Capability Features made available to applications are Registered in the Framework. Before
an application can use the network functionality made available through Service Capability Features,
authentication between the application and framework is needed. After authentication, the discovery function
enables the application to find out which Service Capability Features are provided by the Service Capability
Servers. The Service Capability Features are accessed by the methods defined in the OSA interfaces.
• Service Capability Servers: providing the applications with Service Capability Features, which are abstractions
from underlying network functionality. Examples of Service Capability Features offered by the Service
Capability Servers are Call Control and User Location. Similar Service Capability Features may possibly be
provided by more than one Service Capability Server. For example, Call Control functionality might be provided
by SCSs on top of CAMEL and MExE.
ETSI
3GPP TS 23.198 version 7.3.0 Release 7 10 ETSI TS 123 198 V7.3.0 (2008-01)
Application
server
Application
discovery
OSA API
Interface
Open
class
Service
User Location Call control
Access
framework Service capability server(s)
HSS CSE S-CSCF Servers
E.g. Location server
OSA    MExE server
SAT server
Figure 5.1.1: Overview of Open Service Access
The present document, together with the associated stage 3 specification, defines the OSA APIs. OSA does not mandate
any specific platform or programming language.
The Service Capability Servers that provide the OSA interfaces are functional entities that can be distributed across one
or more physical nodes. For example, the User Location interfaces and Call Control interfaces might be implemented on
a single physical entity or distributed across different physical entities. Furthermore, a service capability server can be
implemented on the same physical node as a network functional entity or in a separate physical node. For example, Call
Control interfaces might be implemented on the same physical entity as the CAMEL protocol stack (i.e. in the CSE) or
on a different physical entity.
Several options exist:
Option 1
The OSA interfaces are implemented in one or more physical entity, but separate from the physical network entities.
Figure 5.1.2 shows the case where the OSA interfaces are implemented in one physical entity, called "gateway" in the
figure. Figure 5.1.3 shows the case where the SCSs are distributed across several "gateways".

OSA API
SCS
"Gateway"
Non-standardized
or standardized
Interfaces
HSS CSE  ….
Functional entity
Physical entity
Figure 5.1.2: SCSs and network functional entities implemented in separate physical entities
ETSI
3GPP TS 23.198 version 7.3.0 Release 7 11 ETSI TS 123 198 V7.3.0 (2008-01)

OSA API
SCS SCS
SCS
"Gateway"
Non-standardized
or standardized
interfaces
CSE
HSS .
Figure 5.1.3: SCSs and network functional entities implemented in separate physical entities,
SCSs distributed across several "gateways"
Option 2
The OSA interfaces are implemented in the same physical entities as the traditional network entities (e.g. HSS, CSE),
see Figure 5.1.4.
OSA API
SCS SCS
SCS
….
HSS CSE
Figure 5.1.4: SCSs and network functional entities implemented in same physical entities
Option 3
Option 3 is the combination of option 1 and option 2, i.e. a hybrid solution.

OSA API
SCS
SCS
"Gateway"
Non-standardized
or standardized
Interface
HSS CSE  ….
Figure 5.1.5: Hybrid implementation (combination of options 1 and 2)
It shall be noted that in all cases there is only one Framework. This framework may reside within one of the physical
entities containing an SCS or in a separate physical entity.
From the application point of view, it shall make no difference which implementation option is chosen, i.e. in all cases
the same network functionality is perceived by the application. The applications shall always be provided with the same
set of interfaces and a common access to framework and Service Capability Feature interfaces. It is the framework that
will provide the applications with an overview of available Service Capability Features and how to make use of them.
ETSI
3GPP TS 23.198 version 7.3.0 Release 7 12 ETSI TS 123 198 V7.3.0 (2008-01)
The implementation of applications that make use of the OSA interfaces is not constrained or limited to a particular
programming language; middleware choice or physical architecture by the OSA interfaces themselves. Applications
may be realized as functional entities that can be distributed across one or more physical entities, e.g. platforms,
processes etc. For example, a logical application providing call routing capability may be realized as a number of
discrete physical applications in order to support differentiated application behaviour; application scalability or
application resilience. However, the logical relationship established between applications, framework and SCFs, must
always be maintained such that the integrity, security and use of the OSA interfaces remains consistent.
A range of options exist that allows applications to be realized as a number of physical entities in a manner that
maintains the integrity of the OSA architecture:
Option 1
The application is produced as a single physical entity.

App
OSA API
Framework SCF
Physical entity
OSA
Internal
Functional entity
API
Figure 5.1.6: Application function implemented as a single physical entity
Option 2
The functionality of the application is realized using multiple physical entities. Figure 5.1.7 and figure 5.1.8 represent
alternative solutions where the same application obtains a reference to the same SCF interface. In figure 5.1.7, each
physical application uses a unique set of interfaces supplied by the Framework for each application access session,
whereas in figure 5.1.8 the Framework shares the same interfaces. In either case the Framework resolves the application
sessions to a single FW-Svc session, and a single service manager is provided to the functional application.

App
OSA API
Framework SCF
Physical entity
OSA
Internal
Functional entity
API
Shared Interface Reference
Figure 5.1.7: Application function implemented in several physical entities
(unique Framework Interface References for each application entity)
ETSI
3GPP TS 23.198 version 7.3.0 Release 7 13 ETSI TS 123 198 V7.3.0 (2008-01)

App
OSA API
Framework SCF
Physical entity
OSA
Internal
Functional entity
API
Shared Interface Reference
Figure 5.1.8: Application function implemented in several physical entities
(sharing common Framework Interface References)
The application examples above depict an OSA Gateway with both Framework and SCF functions supported on a
single physical entity. Further Gateway architectures in which the Framework and SCFs are supported in multiple
discrete physical entities are also possible.
5.2 Basic mechanisms in the Open Service Access
This subclause explains which basic mechanisms are executed in OSA prior to offering and activating applications.
Some of the mechanisms are applied only once (e.g. establishment of service agreement), others are applied each time a
user subscription is made to an application (e.g. enabling the call attempt event for a new user).
Basic mechanisms between Application and Framework:
• Authentication: Once an off-line service agreement exists, the application can access the authentication
function. The authentication model of OSA is a peer-to-peer model. The application must authenticate the
framework and vice versa. The application must be authenticated before it is allowed to use any other OSA
function.
• Authorization: Authorization is distinguished from authentication in that authorization is the action of
determining what a previously authenticated application is allowed to do. Authentication must precede
authorization. Once authenticated, an application is authorized to access certain Service Capability Features.
• Discovery of framework functions and Service Capability Features: After successful authentication,
applications can obtain available framework functions and use the discovery function to obtain information on
authorized Service Capability Features. The Discovery function can be used at any time after successful
authentication.
• Establishment of service agreement: Before any application can interact with a Service Capability Feature, a
service agreement must be established. A service agreement may consist of an off-line (e.g. by physically
exchanging documents) and an on-line part. The application has to sign the on-line part of the service agreement
before it is allowed to access any Service Capability Feature.
• Access to Service Capability Features: The framework must provide access control functions to authorize the
access to Service Capability Features or service data for any API method from an application, with the specified
security level, context, domain, etc.
Basic mechanism between Framework and Service Capability Server:
• Registering of Service Capability Features. SCFs offered by a Service Capability Server can be registered at
the Framework. In this way the Framework can inform the Applications upon request about available Service
Capability Features (Discovery). For example, this mechanism is applied when installing or upgrading a Service
Capability Server.
ETSI
3GPP TS 23.198 version 7.3.0 Release 7 14 ETSI TS 123 198 V7.3.0 (2008-01)
Basic mechanisms between Application Server and Service Capability Server:
• Request of event notifications. This mechanism is applied when a user has subscribed to an application and that
application needs to be invoked upon receipt of events from the network related to the user. For example, when a
user subscribes to an incoming call screening application, the application needs to be invoked when the user
receives a call. It will therefore request to be notified when a call setup is performed, with the user number as
Called Party Number.
5.3 Service Brokering
The service broker function enables the brokering of multiple services in a managed and controlled fashion.

App App App
OSA API
Physical entity
SCF Service Broker
Non-standardized
or standardized
Functional entity
interface
CSE
….
Figure 5.3.1: Service Broker function implemented as separate physical entity
The diagram depicts the interfaces between the various entities requiring brokering of services within the OSA
environment. In this diagram the service broker is identified as an independent physical entity to that which supports the
SCF. This is not mandated, but is depicted to indicate that such an architecture is possible.
The OSA Service Broker API includes the ability to specify provisioning and configuration data required to control the
service brokering.
The messaging interfaces between Service Broker and OSA SCSs or other service delivery nodes/elements is based
upon the network interfaces supported by each system. Note that the above architecture does not preclude the OSA SCS
communicating directly with network entities where service interaction is not required.
ETSI
3GPP TS 23.198 version 7.3.0 Release 7 15 ETSI TS 123 198 V7.3.0 (2008-01)
6 Framework
6.1 Trust and Security Management Functions
The Trust and Security Management functions provide:
• the first point of contact for an application to access a network via the OSA APIs;
• the authentication methods for the application and network to perform a mutual authentication;
• the application with the ability to select a Service Capability Feature to make use of;
• the application with a portal to access other framework functions.
The process by which the application accesses the network via the OSA APIs has been separated into 3 stages, each
supported by a different framework function:
1) Initial Contact with the framework;
2) Authentication to the framework;
3) Access to framework functions and Service Capability Features.
6.1.1 Initial Contact
The application gains a reference to the OSA Initial Contact function for the network that they wish to access. This may
be gained through a URL, a Naming or Trading Service or an equivalent service, a stringified object reference, etc. At
this stage, the application has no guarantee that this is a reference to the network, so it this reference to initiate an
authentication process.
Initial Contact supports a particular method to allow the authentication process to take place (using the Authentication
SCF defined in subclause 6.1.2). This method must be the first invoked by the application. Invocations of other methods
will fail until authentication has been successfully completed.
Once the application has authenticated with the network, it can gain access to other framework functions and Service
Capability Features. This is done by invoking a method, by which the application requests a certain type of access
Service Capability Feature. The OSA Access function is defined in subclause 6.1.3.
6.1.2 Authentication
Once the application has made initial contact with the network, and any time during their interactions, authentication of
the application and network may be required.
The OSA APIs supports multiple authentication techniques. The procedure used to select an appropriate technique for a
given situation is described below. The authentication mechanisms may be supported by cryptographic processes to
provide confidentiality, and by digital signatures to ensure integrity. The inclusion of cryptographic processes and
digital signatures in the authentication procedure depends on the type of authentication technique selected. In some
cases strong authentication may need to be enforced by the network to prevent misuse of resources. In addition it may
be necessary to define the minimum encryption key length that can be used to ensure a high degree of confidentiality.
The application must authenticate with the framework before it is able to use any of the other interfaces supported by
the framework. Invocations on other interfaces will fail until authentication has been successfully completed.
6.1.3 OSA Access
This function supports stage 1 requirements related to authorization and service registration.
During an authenticated session accessing the Framework, the application will be able to select and access an instance
of a framework function or Service Capability Feature.
ETSI
3GPP TS 23.198 version 7.3.0 Release 7 16 ETSI TS 123 198 V7.3.0 (2008-01)
In order to use OSA SCFs, the application must first be authorized to do so by establishing a service agreement with the
network. The application uses the discovery SCF to retrieve the ID of the SCF they wish to use. They may then check
that they are authorized to use the SCF. The network is informed that the application wishes to use the SCF. Finally, a
service agreement is signed digitally between the two parties.
Establishing a service agreement is a business level transaction, which requires the HE-VASP that owns the application
to agree terms for the use of an SCF with the Home Environment. Service agreements can be reached using either off-
line or on-line mechanisms. Off-line agreements will be reached outside of the scope of OSA interactions, and so are
not described here. However, applications can make use of service agreements that are made off-line. Some Home
Environments may only offer off-line mechanisms to reach service agreements.
After a service agreement has been established between the application and the Ho
...