ETSI EG 201 988-2-2003 Services and Protocols for Advanced Networks (SPAN) Service Provider Access Requirements (SPAR) Open Service Access for API requirements Part 2 Version 2 (V1_1.pdf

《ETSI EG 201 988-2-2003 Services and Protocols for Advanced Networks (SPAN) Service Provider Access Requirements (SPAR) Open Service Access for API requirements Part 2 Version 2 (V1_1.pdf》由会员分享，可在线阅读，更多相关《ETSI EG 201 988-2-2003 Services and Protocols for Advanced Networks (SPAN) Service Provider Access Requirements (SPAR) Open Service Access for API requirements Part 2 Version 2 (V1_1.pdf（24页珍藏版）》请在麦多课文档分享上搜索。

1、ETSI EG 201 988-2 1.1.1 (2003-04) ETSI Guide Services and Protocols for Advanced Networks (SPAN); Service Provider Access Requirements (SPAR); Open Service Access for API requirements; Part 2: Version 2 2 ETSI EG 201 988-2 VI .I .I (2003-04) Reference DEGEPAN-141606-2 Keywords API, architecture, int

2、erface, UML ETSI 650 Route des Lucioles F-O6921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 O0 Fax: +33 4 93 65 47 16 Siret No 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-prfecture de Grasse (06) No 7803/88 Important notice Individual copies of the present

3、document can be downloaded from: http:lwmv.etsi .arq 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

4、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 oth

5、er ETSI documents is available at ha p:/pa rta I. etsi I a rgltbistat uslstatus .as p If you find errors in the present document, send your comment to: Cori vriaht Notifica tion No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend t

6、o reproduction in all media. O European Telecommunications Standards Institute 2003. All rights reserved. DECTTM, PLUGTESTSTMand UMTSTMare Trade Marks of ETSI registered for the benefit of its Members. TIPHONTM and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of

7、 its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. ETSI 3 ETSI EG 201 988-2 VI .I .I (2003-04) Contents Intellectual Property Rights . .4 Foreword . 4 Introduction . .4 1 2 3 4 4.1 5 5.1 5.1.1 5.1.2 5.1.3 5.2 5.2.1 5.2.2 5.

8、2.3 5.2.4 5.3 5.3.1 5.3.2 5.4 5.4.1 5.5 5.5.1 5.6 5.6.1 5.6.2 5.7 5.8 5.9 5.9.1 5.9.2 5.9.3 5.9.4 5.9.5 6 6.1 6.2 6.3 6.4 6.5 Scope 5 References . .5 Abbreviations .5 ETSI OSA Phase2/Parlay Phase 4 API domains . .6 Framework interface and service interface . 6 Proposed enhancements to existing inter

9、faces .6 General requirements . Backwards compa precation Emergency preparedness . Balancing up of interfaces . Framework. . Framework information model Framework management tool Enhancements on event notification handling . stration interfaces . s . Packet switching Call Control functions Terminal

10、capabilities . . 13 Discovery of client terminal capabilities . . 13 User interaction . . 14 . 14 Charging issues related to Call Control . . 14 . 14 dia call control . . 14 Event notification . 15 Network controlled notifications . . 15 Content based charging . . 16 Service properties . 16 Support

11、of roaminghulti-network scenarios . 18 Separation of rating and non-rating functional . 18 Split charging . . 19 New interfaces and areas of involvement . 19 . Interact with a user . . User confirmation Information transfer function Presence related capability functions . . . 21 as an alternative tr

12、ansport mechanism Annex A (informative): Bibliography . 23 History . .24 ETSI 4 ETSI EG 201 988-2 VI .I .I (2003-04) 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

13、, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 3 14: “Intellectual Property Rights (7PRs); Essential, orpotentially Essential, IPRs notlJied to ETSI in respect ofETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on

14、the ETSI Web server (5). All published ETSI deliverables shall include information which directs the reader to the above source of information. Foreword This ETSI Guide (EG) has been produced by ETSI Technical Committee Services and Protocols for Advanced Networks (SPAN). The present document is par

15、t 2 of a multi-part deliverable covering Service Provider Access Requirements (SPAR); Open Service Access for API requirements, as identified below: Part 1: “Version 1“; Part 2: “Version 2“; Part 3: “Version 3“. I n t rod uct ion The present document contains the Requirements capture for ETSI Versio

16、n 2 Open Service Access API protocol specification. ETSI 5 ETSI EG 201 988-2 VI .I .I (2003-04) 1 Scope The present document contains the functional requirements for the second phase of the ETSI Open Service Access API, as defiied in ES 202 915 4. The present document has been compiled in conjunctio

17、n with Parlay and represents the fourth phase of the Parlay API. The ETSI and Parlay API has been specified and designed using the requirements identified in the present document. The requirements are intended to provide the necessary functionality for benchmark applications. The new requirements bu

18、ild upon the ETSI OSA Phase 1 API in ES 201 915 3 and the Parlay 3 specification and should be fully backward compatible. This means that any network operator implementing ETSI OSA Phase 2 or Parlay 4 should be able to interwork with a client application provider implementing ETSI OSA Phase 1 or Par

19、lay 3. In other words ETSI OSA Phase 2 and Parlay 4 will retain ETSI OSA Phase 1 and Parlay 3 as a complete subset. 2 Re fe re nces The following documents contain provisions which, through reference in this text, constitute provisions of the present document. References are either specific (identif

20、ied by date of publication andor 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

21、be found at htlu:/docbox.etsi.or:eerence. il ETSI TS 129 198: “Universal Mobile Telecommunications System (UMTS); Open Service Access (OSA) Application Programming Interface (API)“. ETSI TS 123 127: “Universal Mobile Telecommunications System (UMTS); Virtual Home Environment (VHE) / Open Service Acc

22、ess (OSA); Stage 2 (3GPP TS 23.127 version 5.2.0 Release 5)“. 21 31 41 ETSI ES 201 915: “Open Service Access (OSA); Application Programming Interface (API)“. ETSI ES 202 9 15: “Open Service Access (OSA); Application Programming Interface (API)“. 3 Abbreviations For the purposes of the present docume

23、nt, the following abbreviations apply: API ASP cc DSC ETS HTTP IP LIF MIS MPCC OSA PDP SIP SCS SOAP Application Program Interface Advanced Signal Processor Call Control Data Switch Control Emergency Telecommunications Service Hyper Text Transfer Protocol Internet Protocol Location Interoperability F

24、orum Management Information System Multi Protocol Call Control Open Services Access Packet data protocol Session Initiation Protocol Service Capability Server Simple Object Access Protocol ETSI 6 ETSI EG 201 988-2 VI .I .I (2003-04) ss7 Signalling System 7 USSD Unstructured SS Data w3c World Wide We

25、b Consortium XML extended Markup Language 4 ETSI OSA Phase2/Parlay Phase 4 API domains The ETSVParlay API is an open, technology-independent, and extensible interface into networking technologies. The API is therefore applicable to a number of business and application domains, not just telecommunica

26、tions network operators. Examples of business domains that may use the API include: Third Party Telephony Service Providers. Interactive multi-media Service Providers. Corporate Businesses. Small Businesses. Residential Customers. Network Operators. All of these businesses have networking requiremen

27、ts, ranging from simple telephony and call routing to call centres, virtual private networks and fully interactive multi-media. The rest of the present document is structured to capture all of the requirements that are deemed necessary to enhance the existing ETSI OSA Phase 1 and Parlay 3.2 specific

28、ation to an ETSI OSA Phase 2/Parlay 4.0 status. 4.1 Framework interface and service interface 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. Se

29、rvices and the framework functionality will be exposed via interfaces. These interfaces will be called the service interface and framework interface respectively. 5 Proposed enhancements to existing interfaces 5.1 Gen eral req u i re men ts 5.1.1 Backwards compatibiIity/deprecation Source: Parlay Is

30、sueMo tivation: It needs to be considered what can be done if we find that certain interfaces in Parlay 3.1 are found to be unstable and therefore require appropriate modification. If we use the concept of deprecation then we can effectively provide new methods to that interface where the old method

31、s are incorrect. This means that the two methods will exist side by side in the same interface for the same purpose in Parlay 4.0. One method may not be complete but the other is! The methods that are incorrect would be removed in further versions of the API. ETSI 7 ETSI EG 201 988-2 VI .I .I (2003-

32、04) Requirement description: The Parlay 4.0/OSA 2.0/ETSI SPAN 2.0 APIs shall be backwards compatible. This has two aspects: A client application utilizing Parlay 3.0/OSA l.O/ETSI SPAN 1.0 APIs shall run without change (not even re-compilation) against a server providing Parlay 4.0/OSA 2.0/ETSI SPAN

33、2.0 APIs. A deprecation mechanism shall be defined that allows to remove outdated methods or interfaces in a well-defined, step-wise approach. 5.1.2 Emergency preparedness Source: Telcordia IssueMo tivation: There is a need to extend A/IN-based facilities defined for national emergency calls to Next

34、 Generation Networks and APIs. The U.S. Government and other countries have sponsored programs over the past 15 years to ensure, via standards and implementation programs, that National Emergency calls enjoy priority handling, Network Management Control exception and Alternate Carrier Routing, etc.

35、This initiative is known as Emergency Telecommunications Service (ETS). Although this is currently available for voice calls only there is also a need to handle new types of communication (data, email, video, multi-media), new types of networks (wireless, packet) and technology (protocols, architect

36、ures). These requirements impact Call Control and Policy Management and may also impact Mobility, Charging and Framework (e.g. for location-based service, accounting bypass, security, etc.). Requirement description: The Parlay/OSA/ETSI SPAN APIs shall support the Emergency Telecommunications Service

37、. In particular, they shall provide client applications with means to make use of the Emergency Telephony Service. Possible solution and further considerations: To support the Emergency Telecommunications Service, an optional parameter could be provided within the call control and other interfaces (

38、e.g. CC, MPCC, DSC). 5.1.3 Balancing up of interfaces Source: Eurescom IssueMo tivation: Many of the Parlay/OSA/ETSI SPAN APIs are highly asymmetric between application and gateway. As the capabilities of terminals connected to networks continues to grow, network based applications will require grea

39、ter awareness of these capabilities. Likewise, as new network protocols such as SIP, which are peer-to-peer in nature, are developed, new types of functionality and control will become possible. The “Balancing up“ of interfaces is concerned with identiSling areas where the asymmetry of Parlay may ca

40、use limitation in functionality or feature interaction problems. Although many of these asymmetries are particularly apparent on SIP networks, many aspects identified will not be restricted to SIP. The work is aimed at identiSling and suggesting changes to Parlay to help in solving feature interacti

41、on problems and to support fully the flexibility which new networks, protocols and terminals enable. Scenarios: This clause provides scenarios and examples of situations where more balanced interfaces might be beneficial. At present the work is expected to have a broad impact across the service inte

42、rfaces, for example. Cull Control An application can create a new call leg within a call, but a network cannot create a call leg and notiSl an application that a call leg has been created. Terminals and protocols which allow a client to add an additional party to the call should be able to do so, ma

43、king the application aware of the new party. ETSI 8 ETSI EG 201 988-2 VI .I .I (2003-04) An application can attach and detach call legs from a call, but the application cannot be notified that the call legs have been attached or detached by the connected party. This causes problems because if a call

44、er detaches from a call, then the application is not aware of this. In a symmetrical model, the media stream could be connected or disconnected by either application or client, and the application could be notified of changes. Mobility interfaces The mobility interfaces allow an application to query

45、 the status and location of an address. However, an application cannot request notification of incoming requests for the status or location of address and return a response. A scenario where this causes a problem is where a unified communications application provides a “one-number“ service, and a se

46、cond application requests the status or location of the user. The unified communications application must have be able to receive status requests and respond to them. Requirements description: To identiSl aspects of Parlay where asymmetries can cause limitations. This includes call control, mobility

47、, terminal capabilities and user interaction interfaces. To collate the information from the comparisons and to identiSl service scenarios where the existing interfaces are too restrictive and where symmetrical behaviour would be advantageous. To ensure that any symmetrical interfaces proposed do no

48、t compromise compatibility with existing asymmetric networks. Possible solution and further consideration: Modified Parlay interface class diagrams, interface definitions and data types or recommendations via reports. 5.2 Framework 5.2.1 Framework information model Source: Eurescom Issue/Mo tivation

49、: An Information Model for the Parlay/OSA Framework (FIM, Framework Information Model) can answer to several needs, coming from different actors in the possible business models, but the first reason to defie such a model is to have an agreed, common view and a “common language“ to address the same concepts when analysis related to complex data structures, relationships and objects, have to be done. Since work done so far, both on standard and on the vendors side, indicates that the Framework functionality is the heart of the Parlay Gateway system, the availability of a