1、 INTERNATIONAL TELECOMMUNICATION UNION ITU-T Series QTELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Supplement 40(11/2002) SERIES Q: SWITCHING AND SIGNALLING Technical Report: Reference document on API/object interface between network control and application layer ITU-T Q-series Recommendations Sup
2、plement 40 ITU-T Q-SERIES RECOMMENDATIONS SWITCHING AND SIGNALLING SIGNALLING IN THE INTERNATIONAL MANUAL SERVICE Q.1Q.3 INTERNATIONAL AUTOMATIC AND SEMI-AUTOMATIC WORKING Q.4Q.59 FUNCTIONS AND INFORMATION FLOWS FOR SERVICES IN THE ISDN Q.60Q.99 CLAUSES APPLICABLE TO ITU-T STANDARD SYSTEMS Q.100Q.11
3、9 SPECIFICATIONS OF SIGNALLING SYSTEM No. 4 Q.120Q.139 SPECIFICATIONS OF SIGNALLING SYSTEM No. 5 Q.140Q.199 SPECIFICATIONS OF SIGNALLING SYSTEM No. 6 Q.250Q.309 SPECIFICATIONS OF SIGNALLING SYSTEM R1 Q.310Q.399 SPECIFICATIONS OF SIGNALLING SYSTEM R2 Q.400Q.499 DIGITAL EXCHANGES Q.500Q.599 INTERWORKI
4、NG OF SIGNALLING SYSTEMS Q.600Q.699 SPECIFICATIONS OF SIGNALLING SYSTEM No. 7 Q.700Q.799 Q3 INTERFACE Q.800Q.849 DIGITAL SUBSCRIBER SIGNALLING SYSTEM No. 1 Q.850Q.999 PUBLIC LAND MOBILE NETWORK Q.1000Q.1099 INTERWORKING WITH SATELLITE MOBILE SYSTEMS Q.1100Q.1199 INTELLIGENT NETWORK Q.1200Q.1699 SIGN
5、ALLING REQUIREMENTS AND PROTOCOLS FOR IMT-2000 Q.1700Q.1799 SPECIFICATIONS OF SIGNALLING RELATED TO BEARER INDEPENDENT CALL CONTROL (BICC) Q.1900Q.1999 BROADBAND ISDN Q.2000Q.2999 For further details, please refer to the list of ITU-T Recommendations. Q series Supplement 40 (11/2002) i Supplement 40
6、 to ITU-T Q-series Recommendations Technical Report: Reference document on API/object interface between network control and application layer Summary There are many API/Object Interface-related activities outside of ITU-T SG11. Many API/Object Interface specifications have already been released from
7、 such activities and a lot of discussions for new APIs/Object Interfaces are starting within them. However, there is no good reference material to help introduce the API/Object Interface specifications under current discussion and it is difficult to know what kind of APIs are released or discussed.
8、This Supplement provides high-level descriptions of API/Object Interface-related activities outside of ITU-T, covering the interface between network control and application layers. This Supplement should be used as a reference to the other API/Object Interface activities outside of ITU-T. This Suppl
9、ement will also help to avoid the overlapping of the standardization effort. Source Supplement 40 to ITU-T Q-series Recommendations was prepared by ITU-T Study Group 11 (2001-2004) and approved under ITU-T Recommendation A.13 (10/2000) procedure on 22 November 2002. ii Q series Supplement 40 (11/200
10、2) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions a
11、nd issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on th
12、ese topics. The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this publication, the expres
13、sion “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the possibility that the practice or implementation of this publication may involve the use of a claimed Intellectu
14、al Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the publication development process. As of the date of approval of this publication, ITU had not received notice o
15、f intellectual property, protected by patents, which may be required to implement this publication. However, implementors are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database. ITU 2003 All rights reserved. No part of thi
16、s publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. Q series Supplement 40 (11/2002) iii CONTENTS Page 1 Scope 1 2 References. 2 2.1 Website References 2 2.2 Document References. 2 3 Definitions 2 4 Abbreviations 2 5 Activity in each standard body .
17、 2 5.1 Parlay/ETSI/3GPP 2 5.2 JAIN . 9 5.3 OMG. 13 5.4 TINA. 18 6 Applicability . 21 6.1 Objective. 21 6.2 Classification of API 22 6.3 Applicability. 22 Appendix I 25 I.1 Parlay/ETSI/3GPP 25 I.2 JAIN . 26 I.3 OMG. 26 I.4 TINA. 27 Q series Supplement 40 (11/2002) 1 Supplement 40 to ITU-T Q-series Re
18、commendations Technical Report: Reference document on API/object interface between network control and application layer 1 Scope This Supplement provides high level descriptions of API/Object Interface related activities outside of ITU-T and clarifies the applicability of each API/Object Interface s
19、pecification. It focuses on the specifications of API/Object Interface between network control and application layers. It will also help to avoid the overlapping of the standardization effort. The scope of this Supplement is shown in Figure 1. Q.SUPP.40_F1SecurityAuthenticationScope of this API refe
20、rence document3rd Party Application3rd Party ApplicationCall Control ChargingService Management APIsService Management functionsMobility User Interaction etc.Application ApplicationProtocol/Resource APIsNetwork capabilitiesService Control APIs3rd Party APIs3rd Party Application3rd Party ApplicationI
21、SUP H.323 SIP MGCP MEGACO etc.Figure 1 Reference layered model of network The outline of Each API category is as follows. 3rd Party APIs: The APIs in this category are the APIs open for 3rd Party and they provide authentication and security functions. 3rd Party can utilize Service Control APIs and S
22、ervice Management APIs through these APIs. Service Control APIs: The APIs in this category provide network capabilities to control services. The example APIs included in this category are Call Control, Charging, Mobility, User Interaction, etc. Network operators or 3rd Party can develop their applic
23、ations making use of these APIs. Service Management APIs: The APIs in this category provide service management functions such as to support execution, deployment and observation of services, etc. The example APIs included in this category are Service Execution, Deployment, etc. Network operators can
24、 manage services based on these APIs. Protocol/Resource APIs: The APIs in this category provide protocol/resource oriented functions to network capability functions. The APIs in this category are not within the scope of this Supplement. 2 Q series Supplement 40 (11/2002) 2 References 2.1 Website Ref
25、erences w1 Parlay website: http:/www.parlay.org/ w2 ETSI website: http:/docbox.etsi.org/span/open/span12/osa.html w3 3GPP website: http:/www.3gpp.org/ w4 JAIN website: http:/ w5 OMG website: http:/www.omg.org/ w6 TINA website: http:/ 2.2 Document References d1 3GPP TS 21.903 Vocabulary document d2 P
26、arlay website for downloading documents: http:/www.parlay.org/specs/index.asp d3 ETSI website for downloading documents: http:/pda.etsi.org/pda/queryform.asp d4 3GPP website for downloading documents: http:/www.3gpp.org/TB/cn/cn5/specs.htm d5 JAIN website for downloading documents: http:/ d6 JAIN Wh
27、ite Paper: http:/ d7 OMG website for downloading documents: http:/www.omg.org/technology/documents/spec_catalog.htm d8 TINA website for downloading documents: http:/ 3 Definitions The definitions in this Supplement follow the definitions in each standard body (e.g. 3GPP vocabulary document d1). 4 Ab
28、breviations The abbreviations in this Supplement follow the abbreviations in each standard body (e.g. 3GPP vocabulary document d1). 5 Activity in each standard body This clause provides introduction to each activity of API-related standard bodies. 5.1 Parlay/ETSI/3GPP 5.1.1 Overview of joint activit
29、y 5.1.1.1 Overview The Parlay Group w1, ETSI w2, and 3rd Generation Partnership Project (3GPP) w3 are working jointly to define common API for Open Service Access (OSA). Hereafter, the API developed by this joint group is called OSA/Parlay API. A detailed description of each standard body is given i
30、n the following clauses. Q series Supplement 40 (11/2002) 3 The OSA/Parlay APIs are intended to enable a new generation of off-the-shelf network applications and components (e.g. messaging, mobility, end-to-end quality of service) to be developed by application providers (Independent Software Vendor
31、 (ISV)/Application Service Provider (ASP) independent of the underlying voice/multimedia network. Faster time-to-market and a less complex development cycle are some of the expected key benefits of the OSA/Parlay APIs. The OSA/Parlay APIs consist of two categories of interface: Service Interfaces. T
32、hese offer applications access to a range of network capabilities and information. Framework Interfaces. These provide the supporting capabilities necessary for the Service Interfaces to be secure and manageable. 5.1.1.2 Description The OSA/Parlay API uses the Unified Modelling Language (UML) to des
33、cribe access to Third Party Service applications. The API is not a piece of code but provides a mechanism whereby objects transparently make requests to, and receive responses from, other objects on different platforms in heterogeneous environments like Intelligent Networks. Where the OSA/Parlay API
34、 is located in the network is shown in Figure 2. Q.SUPP.41_F2Services/applicationlayerControl layerServices Capability ServersConnectivity layerCore Authentication and Authorisation; Integrity Management. 4 Q series Supplement 40 (11/2002) Q.SUPP.41_F3Telecom NetworkFramework ServiceEnterpriseoperat
35、oradmin toolClientApplicationFrameworkoperatoradminServicesupplieradmin toolFigure 3 The architecture of the Parlay/OSA APIs The current Parlay/OSA API Service Capability Features (SCFs) are shown in Table 1. Table 1 Current Parlay/OSA SCFs Call Control The Call control family, with capabilities ran
36、ging from setting up basic calls to manipulating multimedia conference calls Framework Infrastructure capabilities such as authentication, SCF discovery, SCF registration, fault management, etc. User Interaction Obtain information from the end-user, play announcements, send short text messages, etc.
37、 User location/User status Obtain location and status information Terminal capabilities Obtain the capabilities of an end-user terminal Data session control Control of data sessions Generic Messaging Access to mailboxes Connectivity Management Provisioned QoS Account Management Access end-user accou
38、nts Content based Charging Charge end-users for use of applications / data Policy Management Tasks include the creation, update, deletion and viewing of Policy information Presence and Availability Management Management of information relating to presence, such as the dynamic state of devices / soft
39、ware and their owners The API is object-oriented and consists of several categories of interfaces. Generic service interfaces The API is split into two types of interface class descriptions, Service and Framework. Framework classes are those that are perceived to be applicable to the interface irres
40、pective of the type of service that is being implemented at a specific moment in time e.g. Authentication, whereas Service Interface classes are individual services that may be required by the client or network operator to enable the running of third party applications over the interface, e.g. Messa
41、ging type service. Q series Supplement 40 (11/2002) 5 Each of the service capability feature description defines 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 o
42、f the methods (API calls) supported by that interface and the relevant parameters and types. Framework interfaces The Framework is split into two different sections, the first addressing the Client view. The second addresses the relationship between the Service and Framework providers. The client-to
43、-Framework section is split into 5 parts, these being; Trust and Security Framework (which includes Authentication), Fault Management, Integrity Management, Service Subscription and Service Discovery. The Service-to-framework interface contains all of the same interfaces except for Service Subscript
44、ion. Service data definitions Service Data Definitions provides the Data Definitions necessary to support the Generic Service interface. For instance the Generic Call Control Service Data Definitions describes each of the Data types that were shown in the detailed parameter descriptions made in the
45、Generic Call Control Service Interface part and so on. Framework data definitions Framework Data Definitions once again provide the Data Definitions necessary to support the Framework interface. Common data definitions Common Data Definitions provide the Data definitions that are common to both the
46、Framework and Generic Service API parameters. Sequence Transition Diagrams (STDs) Sequence Transition Diagrams contains the sequence transition diagrams from each service. They are used to enhance the understanding of each service in more detail. OMG IDL OMG IDL provides an OMG IDL version of the wh
47、ole API. It was felt useful that a working version of the API be produced so that the API could be realizable in the marketplace of today. 5.1.2 Parlay 5.1.2.1 Overview The Parlay Group is an open, multi-vendor forum organized to create open, technology-independent Application Programming Interfaces
48、 (APIs) which enable IT companies, ASPs, ISVs, Internet Companies, e-Business Companies, software creators, service bureaux, and large and small enterprises as well as network providers, network equipment vendors and application suppliers to develop applications across multiple networks. The Parlay
49、Group is studying the enhancement of its APIs for enlarging their field of application in addition to Parlay/OSA APIs discussed in the joint group. 5.1.2.2 Description The architecture of Parlay API is the same as that of Parlay/OSA API and it is shown in Figure 3. The implementation of Parlay is based on application
