1、 ETSI EG 201 988-3 V1.1.1 (2005-07)ETSI Guide Telecommunications and Internet converged Services andProtocols for Advanced Networking (TISPAN);Service Provider Access;Open Service Access for API requirements;Part 3: Version 3ETSI ETSI EG 201 988-3 V1.1.1 (2005-07) 2 Reference DEG/TISPAN-02009-OSA Ke
2、ywords API, architecture, interface, 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 enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice Indivi
3、dual 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
4、 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 curr
5、ent 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 reproduc
6、ed except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2005. All rights reserved. DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of its Members.
7、 TIPHONTMand the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. ETSI ETSI EG 201 988-3 V1.1.1 (2005-07) 3 Contents Intellectual Property R
8、ights4 Foreword.4 Introduction 4 1 Scope 5 2 References 5 3 Abbreviations .5 4 ETSI 3.0/Phase 5 Parlay API Domains 5 4.1 Framework interface and Service Interface6 5 Proposed enhancements to existing Interfaces.6 5.1 General requirements .6 5.1.1 Backwards Compatibility/Deprecation.6 5.2 Framework .
9、6 5.2.1 Federation of Frameworks 6 6 New interfaces and areas of involvement.7 6.1 Policy Management7 6.2 Multi-media Messaging function .8 6.3 User location 8 6.4 Text to Speech and Speech to Text functions.9 6.5 Requirements on interfaces at different levels of abstractions .10 6.6 User-Applicatio
10、n Authentication functions10 6.7 User Binding functions.11 Annex A (informative): Bibliography.12 History 13 ETSI ETSI EG 201 988-3 V1.1.1 (2005-07) 4 Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaini
11、ng 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 Secretaria
12、t. 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
13、updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This ETSI Guide (EG) has been produced by ETSI Technical Committee Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN). The present document
14、is part 3 of a multi-part deliverable covering Service Provider Access; Open Service Access for API requirements, as identified below: Part 1: “Version 1“; Part 2: “Version 2“; Part 3: “Version 3“. Introduction The present document contains the Requirements capture for ETSI 3.0 “Third Party API“ pro
15、tocol specification ES 203 915 series 1. ETSI ETSI EG 201 988-3 V1.1.1 (2005-07) 5 1 Scope The present document contains the functional requirements for Open Service Access API Requirements Version 3.0. The present document has been compiled in conjunction with Parlay and represents the fifth phase
16、of the Parlay API. The ETSI and Parlay API have been specified and designed using the requirements identified in the present document. The requirements are intended to provide the necessary functionality for benchmark applications. It is the intention that the new requirements should build upon the
17、ETSI Phase 2.0 API and that of the Parlay 4.0 specification and should be fully backward compatible. This means that any network operator implementing ETSI Phase 3.0 or Parlay 5.0 should be able to interwork with a client application provider implementing ETSI Phase 2.0 or Parlay 4.0. In other words
18、 ETSI Phase 3.0 and Parlay 5.0 will retain ETSI Phase 2.0 and Parlay 4.0 as a complete subset. 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 publicati
19、on 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:/docbo
20、x.etsi.org/Reference. 1 ETSI ES 203 915 series: “Open Service Access (OSA); Application Programming Interface (API)“. 2 ETSI TS 122 127: “Universal Mobile Telecommunications System (UMTS); Service Requirement for the Open Services Access (OSA); Stage 1 (3GPP TS 22.127)“. 3 Abbreviations For the purp
21、oses of the present document, the following abbreviations apply: API Application Program Interface ASP Application Service ProviderIP Internet Protocol ISDN Integrated Service Digital Network SS7 Signalling System 7 UI User Interaction 4 ETSI 3.0/Phase 5 Parlay API Domains The Parlay/OSA API is an o
22、pen, technology-independent, and extensible interface into networking technologies. The Parlay API is therefore applicable to a number of business and application domains, not just telecommunications network operators. Examples of business domains that may use the API include: Third Party Telephony
23、Service Providers. Interactive Multimedia Service Providers. ETSI ETSI EG 201 988-3 V1.1.1 (2005-07) 6 Corporate Businesses. Small Businesses. Residential Customers. Network Operators. All of these businesses have networking requirements, ranging from simple telephony and call routing to call centre
24、s, virtual private networks and fully interactive multimedia. The API provides the common interfaces to a variety of services. For the services to work together in a coherent fashion, “framework“ functions are required and are also included in the present document. The remainder of the present docum
25、ent captures the requirements for the ETSI Phase 3.0 and Parlay 5.0 specification. 4.1 Framework interface and Service Interface Services and the framework functionality will be exposed via interfaces. These interfaces will be called the service interface and framework interface respectively. 5 Prop
26、osed enhancements to existing Interfaces 5.1 General requirements 5.1.1 Backwards Compatibility/Deprecation Source: Parlay Issues donor framework: it is a federated framework that makes a specific SCF visible to the corresponding one or more federated frameworks (the receiver framework); receiver fr
27、amework: it is a federated framework that can access a specific SCF offered by a corresponding federated framework (the donor framework); federated SCF: it is an SCF provided by a donor framework and accessed by a receiver framework. The federation function enables a “donor“ framework to limit the a
28、ccess to the registered SCFs from the federated frameworks, i.e.: a “donor“ framework shall be able to discriminate the set of SCFs visible to the federated frameworks; a “donor“ framework shall be able to set some service properties to constraints the usage of its SCFs by the applications authentic
29、ated by a federated framework. Federation function enables a “donor“ framework to maintain the full control of its registered SCFs, i.e. handling the integrity management of the SCFs, controlling the access to the SCFs, etc. Federation function enables the exchange of the information among the feder
30、ated frameworks concerning the SCFs availability and the associated service properties. An SCF shall not be aware of the fact that is a “federated“ SCF and that may be accessed by applications authenticated by different federated frameworks: therefore, the SCF does not have to support additional fun
31、ctions to handle federation. An application shall not be aware that it is interacting with SCFs registered on different federated frameworks. 6 New interfaces and areas of involvement 6.1 Policy Management Source: 3GPP S1-021721 and S1-021722 (Durango) Issues put messages in the mailbox for storage
32、or for sending by the messaging system (with a copy in the mailbox); cancel a message previously sent or query the status of a message previously sent; manipulate folders and messages in the mailbox (e.g. copy, move, delete); list messages in the mailbox and retrieve complete messages, message heade
33、rs, message body or parts of the message body. 6.3 User location Source: S1-021716 Durango (inclusion of LCS enhanced User privacy) Issues accuracy (value depending on local regulatory requirements and level of support in serving/home networks; note that the accuracy of the serving network might dif
34、fer from that in the home environment); age of location information (last known date/time made available in GMT). The following functions shall be provided: report of location information: - the application shall be able to request user location information; - by default the location information is
35、provided once; the application may also request periodic location reporting (i.e. multiple reports spread over a period of time). ETSI ETSI EG 201 988-3 V1.1.1 (2005-07) 9 notification of location update: - the application shall be able to request to be notified when the users location changes, i.e.
36、 when: square4 the user enters or leaves a specified geographic area; square4 the users location changes more than a specified lower boundary. The lower boundary can be selected from the options provided by the network. The application shall be able for each user to start/stop receipt of notificatio
37、ns and to modify the required accuracy by selecting another option from the network provided options. Access control to location information: - the user shall be able to restrict/allow access to the location information. The restriction can be overridden by the network operator when appropriate (e.g
38、. emergency calls). 6.4 Text to Speech and Speech to Text functions Source: N5 - 021045 CN5 #21 Dublin Issues it shall be possible to introduce them in an incremental way; they should allow the creation of applications triggered by network events. The interfaces shall be defined using state of the a
39、rt specification formalisms (e.g., UML, WSDL), and realized using different distributed processing technologies, including CORBA and Web Services. 6.6 User-Application Authentication functions Source: TS 122 127 2 Version 6.7.0 latest text Issues this requires the application to provide as an input
40、the subscribers credentials, which enable secure method of authentication (e.g. subscribers certificates). The User-Application Authentication functions shall return to the invoking application an “application-specific user identifier“ (a true identity or alias) that identifies the authenticated use
41、r, when requested by the application. The identifier may be used by the application to recognize a user through several accesses to the application; it may also be used by the application as a parameter in invocation of other OSA network functions (e.g. for User Location function). The User-Applicat
42、ion Authentication functions shall support privacy settings defined by the user. If the subscribers privacy settings so require, the “application-specific user identifier“, returned by User-Application Authentication function to the invoking application, shall be an alias. Otherwise, the “applicatio
43、n-specific user identifier“ shall be the true identity of the subscriber (e.g. MSISDN). When the application invokes OSA Network functions related to subscriber (e.g. Location, Presence), the subscribers identifier shall be included in the request. An application may request it from the User-Applica
44、tion Authentication function. When an OSA Network function receives the request from the application and the subscribers identifier is an alias, the OSA Network Function shall invoke the User-Application Authentication function to translate the alias to the subscribers true identity (e.g. MSISDN). 6
45、.7 User Binding functions Source: Telcordia/NTT N5-030626 Bangkok Oct03 Issues Open Service Access (OSA); Stage 2 (3GPP TS 23.198)“. ETSI TS 123 127: “Universal Mobile Telecommunications System (UMTS); Virtual Home Environment (VHE) / Open Service Access (OSA) (3GPP TS 23.127)“. ETSI ETSI EG 201 988-3 V1.1.1 (2005-07) 13History Document history V1.1.1 May 2005 Membership Approval Procedure MV 20050701: 2005-05-03 to 2005-07-01 V1.1.1 July 2005 Publication
