SIST ES 201 915-3 V1.4.1:2005

• Abstract:

  Maintenance update of ES 201 915-3 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-3 V1.4.1 (2003-07) - Open Service Access (OSA); Application Programming Interface (API); Part 3: Framework (Parlay 3)

SIST ES 201 915-3 V1.4.1:2005 is the Slovenian adoption of ETSI ES 201 915-3 V1.4.1, Open Service Access (OSA); Application Programming Interface (API); Part 3: Framework (Parlay 3). Published by SIST, it specifies the OSA Framework API used by application developers, enterprise operators, and service providers to authenticate, discover, subscribe to, and manage network services through standardized interfaces.

The standard focuses on the framework side of OSA. It defines the interface structure, methods, state behavior, data definitions, and OMG IDL needed to implement those interfaces.

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

SIST ES 201 915-3 V1.4.1:2005 specifies the Framework part of the OSA Stage 3 API. Clause 1 says the document covers the framework aspects of the interface and organizes them as sequence diagrams, class diagrams, interface specifications with detailed methods, state transition diagrams, data definitions, and an IDL description.

The framework is split into three interface sets:

• Framework to Application
• Framework to Enterprise Operator
• Framework to Service

That split matters because each role uses the API differently. Applications discover and use services, enterprise operators manage subscriptions and service profiles, and services interact with the framework for registration, discovery, lifecycle, and integrity management.

Annex	What it covers
Annex A	OMG IDL description of the Framework
Annex B	Contents of 3GPP OSA R4 Framework
Annex C	Record of changes, including interfaces, methods, data definitions, service properties, exceptions, and other items

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

SIST ES 201 915-3 V1.4.1:2005 is built around a few operational rules that shape every implementation. These rules matter in practice because they determine how a framework must behave when an interface is supported, how parties authenticate, how services are found and selected, and how the framework reports faults or load conditions.

Support and error handling

Clause 4.1 says an implementation that supports a method shall implement its functionality for at least one valid set of parameter values. Where a framework or service interface method is not supported, the call shall return P_METHOD_NOT_SUPPORTED.

That distinction is important for integration work. A client application can call an application interface method even if it is not supported, and no exception is returned, while unsupported framework or service methods must fail explicitly.

Trust and security management

Clauses 6.1 and 6.3 define initial access, authentication, and callback access. The application must authenticate before it can use other OSA interfaces, and the document allows both the default OSA API level authentication and alternative authentication mechanisms.

In practice, the client first initiates authentication, then selects an encryption method, then completes challenge-response authentication. The framework can also require or allow callback references, and the client can obtain interface references only after the access session is established. Methods such as listInterfaces(), obtainInterface(), obtainInterfaceWithCallback(), and releaseInterface() control which framework interfaces are visible during the session.

Service discovery and selection

Clause 7.3.1 defines how an application finds a suitable service. The application can list service types, inspect a service type description, discover services by desired properties, and list services it has already subscribed to.

This matters because service selection is property-based, not just name-based. The application does not only ask “what exists?” - it narrows the choice by matching service properties to the service it needs.

Service agreement and subscription

Clause 7.3.2 and Clause 8 define how a service is selected and contracted. selectService() returns a service token, and signServiceAgreement() uses the token, the agreement text, and a signing algorithm to establish the agreement. The document also says a service token has a limited lifetime, and P_INVALID_SERVICE_TOKEN is returned if it expires.

The enterprise operator part is equally important. The framework supports client application management, Subscription Assignment Groups (SAG), service profiles, and service contracts. A service profile is a restriction of a service contract, and it can be assigned to a SAG so that groups of client applications inherit the same service conditions.

Integrity management

Clauses 7.3.3 and 9.3.4 cover load management, heartbeat supervision, fault handling, and operational availability. The framework and application can monitor each other with heartbeat exchanges, request activity tests, exchange fault reports, and notify each other when a service or framework becomes unavailable.

This is practical operational protection. The application can report its current load, receive load-level notifications, suspend or resume those notifications, and take part in balancing or throttling decisions. The load model uses levels 0, 1, and 2, so implementations need a clear way to report congestion status and react to load changes.

Event notification and service registration

Clauses 7.3.4 and 9.3.1 cover generic event notification and service registration. The application can create and destroy notifications, and the framework returns an assignment ID to identify the registered event criteria.

On the service side, the framework supports service discovery, registration, announcement, and lifecycle management. That lets service suppliers register service capability features, announce availability, and control the service instance lifecycle in a consistent way.

Service properties and identifiers

Clause 10 defines the general service properties used to describe service instances, including service name, version, service instance ID, service instance description, product name, product version, supported interfaces, and operation set.

In practice, these properties are what make discovery and selection work. They give the framework and the client a common description of what a service is, how it differs from other services, and which interfaces it exposes.

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

• OSA - Open Service Access, the architecture that lets application developers use network functionality through an open standardized interface.
• API - Application Programming Interface, the interface boundary between applications, enterprise operators, services, and the framework.
• SCS - Network Service Capability Server, the network-side element that provides service capability features to the framework.
• SCF - Service Capability Feature, the service element that is discovered, registered, selected, and managed through the framework.
• SAG - Subscription Assignment Group, a group of client applications that can share the same service profile assignment.
• IDL - Interface Definition Language, used in Annex A to describe the framework interfaces.
• UML - Unified Modelling Language, the modeling technique used for the sequence, class, and state diagrams.

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

SIST ES 201 915-3 V1.4.1:2005 is used by teams building or integrating OSA-based telecom services. Application developers use it to implement client callbacks, authentication, service discovery, and service agreement flows.

Enterprise operators use it to manage client applications, SAGs, service profiles, and service contracts inside the framework domain. Service suppliers and framework operators use it to register services, announce availability, handle lifecycle control, and implement load, heartbeat, and fault management.

Test and quality teams use the sequence diagrams, state diagrams, and exception model to verify that implementations react correctly under normal use, overload, loss of service, and authentication failure. The document is relevant in telecommunication systems and network service platforms.

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

SIST ES 201 915-3 V1.4.1:2005 is a maintenance update of ES 201 915-3 v.1.3.1. The updated document is also known as Parlay 3.3, and the scope says that only the parts requiring modification are updated, with most parts receiving maintenance fixes.

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

Clause 2 points to ES 201 915-1, Open Service Access; Application Programming Interface; Part 1: Overview (Parlay 3). That part provides the overview, and its terms and abbreviations apply here.

Clause 11 says that common data definitions not defined in this part may be found in ES 201 915-2. That companion part supplies the shared data types used across the API specification.

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

The document contains the full interface description of the OSA Framework API, including method signatures, parameters, return values, and exceptions. It also includes sequence diagrams for authentication, discovery, subscription, integrity management, and service registration.

It contains class diagrams and state transition diagrams for the main framework objects, plus a large set of framework, trust, integrity, event, and subscription data definitions. Annex A provides the OMG IDL description, Annex B lists the contents of 3GPP OSA R4 Framework, and Annex C records changes by interfaces, methods, data definitions, service properties, and exceptions.

The document also uses figures to explain the subscription business model, the relationship between client applications, SAGs, service profiles, and service contracts, and the main interface packages.

SLOVENSKI STANDARD
01-januar-2005
Odprti dostop do storitve (OSA) – Vmesnik za aplikacijsko programiranje (API) – 3.
del: Okvir
Open Service Access (OSA); Application Programming Interface (API); Part 3:
Framework (Parlay 3)
Ta slovenski standard je istoveten z: ES 201 915-3 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 3: Framework
(Parlay 3)
�
2 ETSI ES 201 915-3 V1.4.1 (2003-07)

Reference
RES/SPAN-120095-3
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-3 V1.4.1 (2003-07)
Contents
Intellectual Property Rights.9
Foreword.9
1 Scope.10
2 References.10
3 Definitions and abbreviations.10
3.1 Definitions.10
3.2 Abbreviations.10
4 Overview of the Framework.10
4.1 General requirements on support of methods.12
5 The Base Interface Specification.12
5.1 Interface Specification Format .12
5.1.1 Interface Class.12
5.1.2 Method descriptions.13
5.1.3 Parameter descriptions.13
5.1.4 State Model.13
5.2 Base Interface.13
5.2.1 Interface Class IpInterface .13
5.3 Service Interfaces.13
5.3.1 Overview.13
5.4 Generic Service Interface .13
5.4.1 Interface Class IpService .13
6 Framework Access Session API.15
6.1 Sequence Diagrams.15
6.1.1 Trust and Security Management Sequence Diagrams .15
6.1.1.1 Initial Access for trusted parties.15
6.1.1.2 Initial Access.15
6.1.1.3 Authentication.17
6.1.1.4 API Level Authentication.17
6.2 Class Diagrams.19
6.3 Interface Classes.19
6.3.1 Trust and Security Management Interface Classes .19
6.3.1.1 Interface Class IpClientAPILevelAuthentication.20
6.3.1.2 Interface Class IpClientAccess.21
6.3.1.3 Interface Class IpInitial .22
6.3.1.4 Interface Class IpAuthentication.23
6.3.1.5 Interface Class IpAPILevelAuthentication .24
6.3.1.6 Interface Class IpAccess .26
6.4 State Transition Diagrams .28
6.4.1 Trust and Security Management State Transition Diagrams .29
6.4.1.1 State Transition Diagrams for IpInitial .29
6.4.1.1.1 Active State.29
6.4.1.2 State Transition Diagrams for IpAPILevelAuthentication.29
6.4.1.2.1 Idle State.30
6.4.1.2.2 Selecting Method State.30
6.4.1.2.3 Authenticating Client State.30
6.4.1.2.4 Client Authenticated State.30
6.4.1.3 State Transition Diagrams for IpAccess.31
6.4.1.3.1 Active State.31
7 Framework-to-Application API.32
7.1 Sequence Diagrams.32
7.1.1 Event Notification Sequence Diagrams .32
7.1.1.1 Enable Event Notification .32
ETSI
4 ETSI ES 201 915-3 V1.4.1 (2003-07)
7.1.2 Integrity Management Sequence Diagrams .33
7.1.2.1 Load Management: Suspend/resume notification from application.33
7.1.2.2 Load Management: Framework queries load statistics .34
7.1.2.3 Load Management: Framework callback registration and Application load control .35
7.1.2.4 Load Management: Application reports current load condition.36
7.1.2.5 Load Management: Application queries load statistics.36
7.1.2.6 Load Management: Application callback registration and load control.37
7.1.2.7 Heartbeat Management: Start/perform/end heartbeat supervision of the application .38
7.1.2.8 Fault Management: Framework detects a Service failure .39
7.1.2.9 Fault Management: Application requests a Framework activity test .40
7.1.3 Service Discovery Sequence Diagrams .40
7.1.3.1 Service Discovery.40
7.1.4 Service Agreement Management Sequence Diagrams .42
7.1.4.1 Service Selection.42
7.2 Class Diagrams.44
7.3 Interface Classes.47
7.3.1 Service Discovery Interface Classes.47
7.3.1.1 Interface Class IpServiceDiscovery .47
7.3.2 Service Agreement Management Interface Classes.50
7.3.2.1 Interface Class IpAppServiceAgreementManagement .50
7.3.2.2 Interface Class IpServiceAgreementManagement .52
7.3.3 Integrity Management Interface Classes.55
7.3.3.1 Interface Class IpAppFaultManager .55
7.3.3.2 Interface Class IpFaultManager .58
7.3.3.3 Interface Class IpAppHeartBeatMgmt.61
7.3.3.4 Interface Class IpAppHeartBeat.62
7.3.3.5 Interface Class IpHeartBeatMgmt.63
7.3.3.6 Interface Class IpHeartBeat .64
7.3.3.7 Interface Class IpAppLoadManager .65
7.3.3.8 Interface Class IpLoadManager .67
7.3.3.9 Interface Class IpOAM .71
7.3.3.10 Interface Class IpAppOAM .72
7.3.4 Event Notification Interface Classes.72
7.3.4.1 Interface Class IpAppEventNotification .72
7.3.4.2 Interface Class IpEventNotification .73
7.4 State Transition Diagrams .74
7.4.1 Service Discovery State Transition Diagrams .75
7.4.1.1 State Transition Diagrams for IpServiceDiscovery.75
7.4.1.1.1 Active State.75
7.4.2 Service Agreement Management State Transition Diagrams .75
7.4.3 Integrity Management State Transition Diagrams .76
7.4.3.1 State Transition Diagrams for IpLoadManager.76
7.4.3.1.1 Idle State.76
7.4.3.1.2 Notification Suspended State.76
7.4.3.1.3 Active State.76
7.4.3.2 State Transition Diagrams for LoadManagerInternal.77
7.4.3.2.1 Normal load State.77
7.4.3.2.2 Application Overload State .77
7.4.3.2.3 Internal overload State.77
7.4.3.2.4 Internal and Application Overload State .77
7.4.3.3 State Transition Diagrams for IpOAM.78
7.4.3.3.1 Active State.78
7.4.3.4 State Transition Diagrams for IpFaultManager.78
7.4.3.4.1 Framework Active State.79
7.4.3.4.2 Framework Faulty State.79
7.4.3.4.3 Framework Activity Test State.79
7.4.3.4.4 Service Activity Test State .79
7.4.4 Event Notification State Transition Diagrams .79
7.4.4.1 State Transition Diagrams for IpEventNotification .79
7.4.4.1.1 Idle State.80
7.4.4.1.2 Notification Active State.80
ETSI
5 ETSI ES 201 915-3 V1.4.1 (2003-07)
8 Framework-to-Enterprise Operator API.80
8.1 Sequence Diagrams.84
8.1.1 Service Subscription Sequence Diagrams.84
8.1.1.1 Service Discovery and Subscription Scenario.84
8.1.1.2 Enterprise Operator and Client Application Subscription Management Sequence Diagram .85
8.2 Class Diagrams.88
8.3 Interface Classes.89
8.3.1 Service Subscription Interface Classes .89
8.3.1.1 Interface Class IpClientAppManagement .89
8.3.1.2 Interface Class IpClientAppInfoQuery .93
8.3.1.3 Interface Class IpServiceProfileManagement .95
8.3.1.4 Interface Class IpServiceProfileInfoQuery .98
8.3.1.5 Interface Class IpServiceContractManagement .99
8.3.1.6 Interface Class IpServiceContractInfoQuery .101
8.3.1.7 Interface Class IpEntOpAccountManagement.103
8.3.1.8 Interface Class IpEntOpAccountInfoQuery .104
8.4 State Transition Diagrams .104
8.4.1 Service Subscription State Transition Diagrams.104
9 Framework-to-Service API.105
9.1 Sequence Diagrams.105
9.1.1 Service Discovery Sequence Diagrams .105
9.1.2 Service Registration Sequence Diagrams .105
9.1.2.1 New SCF Registration.105
9.1.3 Service Instance Lifecycle Manager Sequence Diagrams .107
9.1.3.1 Sign Service Agreement.107
9.1.4 Integrity Management Sequence Diagrams .108
9.1.4.1 Load Management: Service callback registration and load control.108
9.1.4.2 Load Management: Framework callback registration and service load control.109
9.1.4.3 Load Management: Client and Service Load Balancing.110
9.1.4.4 Heartbeat Management: Start/perform/end heartbeat supervision of the service.111
9.1.4.5 Fault Management: Service requests Framework activity test.111
9.1.4.6 Fault Management: Service requests Application activity test .112
9.1.4.7 Fault Management: Application requests Service activity test .113
9.1.4.8 Fault Management: Application detects service is unavailable.114
9.1.5 Event Notification Sequence Diagrams .114
9.2 Class Diagrams.115
9.3 Interface Classes.117
9.3.1 Service Registration Interface Classes.117
9.3.1.1 Interface Class IpFwServiceRegistration .118
9.3.2 Service Instance Lifecycle Manager Interface Classes.121
9.3.2.1 Interface Class IpServiceInstanceLifecycleManager .121
9.3.3 Service Discovery Interface Classes.122
9.3.3.1 Interface Class IpFwServiceDiscovery .123
9.3.4 Integrity Management Interface Classes.125
9.3.4.1 Interface Class IpFwFaultManager .125
9.3.4.2 Interface Class IpSvcFaultManager .128
9.3.4.3 Interface Class IpFwHeartBeatMgmt.133
9.3.4.4 Interface Class IpFwHeartBeat .134
9.3.4.5 Interface Class IpSvcHeartBeatMgmt.134
9.3.4.6 Interface Class IpSvcHeartBeat .136
9.3.4.7 Interface Class IpFwLoadManager .136
9.3.4.8 Interface Class IpSvcLoadManager .140
9.3.4.9 Interface Class IpFwOAM .142
9.3.4.10 Interface Class IpSvcOAM .143
9.3.5 Event Notification Interface Classes.144
9.3.5.1 Interface Class IpFwEventNotification.144
9.3.5.2 Interface Class IpSvcEventNotification .145
9.4 State Transition Diagrams .146
9.4.1 Service Registration State Transition Diagrams .147
9.4.1.1 State Transition Diagrams for IpFwServiceRegistration.147
9.4.1.1.1 SCF Registered State.147
ETSI
6 ETSI ES 201 915-3 V1.4.1 (2003-07)
9.4.1.1.2 SCF Announced State.147
9.4.2 Service Instance Lifecycle Manager State Transition Diagrams .147
9.4.3 Service Discovery State Transition Diagrams .148
9.4.4 Integrity Management State Transition Diagrams .148
9.4.4.1 State Transition Diagrams for IpFwLoadManager.148
9.4.4.1.1 Idle State.148
9.4.4.1.2 Notification Suspended State.148
9.4.4.1.3 Active State.148
9.4.5 Event Notification State Transition Diagrams .149
10 Service Properties.149
10.1 Service Property Types .149
10.2 General Service Properties .150
10.2.1 Service Name.150
10.2.2 Service Version.150
10.2.3 Service Instance ID.150
10.2.4 Service Instance Description.150
10.2.5 Product Name.150
10.2.6 Product Version.150
10.2.7 Supported Interfaces.150
10.2.8 Operation Set.150
11 Data Definitions.151
11.1 Common Framework Data Definitions .151
11.1.1 TpClientAppID.151
11.1.2 TpClientAppIDList.151
11.1.3 TpDomainID.151
11.1.4 TpDomainIDType.152
11.1.5 TpEntOpID.152
11.1.6 TpPropertyName.152
11.1.7 TpPropertyValue.152
11.1.8 TpProperty.152
11.1.9 TpPropertyList.152
11.1.10 TpEntOpIDList.152
11.1.11 TpFwID.152
11.1.12 TpService.153
11.1.13 TpServiceList.153
11.1.14 TpServiceDescription.153
11.1.15 TpServiceID.153
11.1.16 TpServiceIDList.153
11.1.17 TpServiceInstanceID.153
11.1.18 TpServiceSpecString.153
11.1.19 TpServiceTypeProperty.154
11.1.20 TpServiceTypePropertyList.154
11.1.21 TpServiceTypePropertyMode.154
11.1.22 TpServicePropertyTypeName.154
11.1.23 TpServicePropertyName.154
11.1.24 TpServicePropertyNameList.154
11.1.25 TpServicePropertyValue.154
11.1.26 TpServicePropertyValueList.154
11.1.27 TpServiceProperty.155
11.1.28 TpServicePropertyList.155
11.1.29 TpServiceSupplierID.155
11.1.30 TpServiceTypeDescription.155
11.1.31 TpServiceTypeName.155
11.1.32 TpServiceTypeNameList.156
11.1.33 TpSubjectType.156
11.2 Event Notification Data Definitions.156
11.2.1 TpFwEventName.156
11.2.2 TpFwEventCriteria.156
11.2.3 TpFwEventInfo.157
11.3 Trust and Security Management Data Definitions .157
ETSI
7 ETSI ES 201 915-3 V1.4.1 (2003-07)
11.3.1 TpAccessType.157
11.3.2 TpAuthType.157
11.3.3 TpEncryptionCapability.158
11.3.4 TpEncryptionCapabilityList.158
11.3.5 TpEndAccessProperties.158
11.3.6 TpAuthDomain.158
11.3.7 TpInterfaceName.159
11.3.8 TpInterfaceNameList.159
11.3.9 TpServiceToken.159
11.3.10 TpSignatureAndServiceMgr.159
11.3.11 TpSigningAlgorithm.160
11.4 Integrity Management Data Definitions .160
11.4.1 TpActivityTestRes.160
11.4.2 TpFaultStatsRecord.160
11.4.3 TpFaultStats.160
11.4.4 TpFaultStatisticsError.160
11.4.5 TpFaultStatsSet.161
11.4.6 TpActivityTestID.161
11.4.7 TpInterfaceFault.161
11.4.8 TpSvcUnavailReason.161
11.4.9 TpFwUnavailReason.161
11.4.10 TpLoadLevel.161
11.4.11 TpLoadThreshold.162
11.4.12 TpLoadInitVal.162
11.4.13 TpLoadPolicy.162
11.4.14 TpLoadStatistic.162
11.4.15 TpLoadStatisticList.162
11.4.16 TpLoadStatisticData.162
11.4.17 TpLoadStatisticEntityID.163
11.4.18 TpLoadStatisticEntityType.163
11.4.19 TpLoadStatisticInfo.163
11.4.20 TpLoadStatisticInfoType.163
11.4.21 TpLoadStatisticError.163
11.5 Service Subscription Data Definitions .164
11.5.1 TpPropertyName.164
11.5.2 TpPropertyValue.164
11.5.3 TpProperty.164
11.5.4 TpPropertyList.164
11.5.5 TpEntOpProperties.
...