1、 INTERNATIONAL TELECOMMUNICATION UNION ITU-T Series QTELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Supplement 48(03/2004) SERIES Q: SWITCHING AND SIGNALLING Guideline document for specifying API/object interface between network control and application layer ITU-T Q-series Recommendations Supplemen
2、t 48 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.119 SPEC
3、IFICATIONS OF SIGNALLING SYSTEMS No. 4, 5, 6, R1 AND R2 Q.120Q.499 DIGITAL EXCHANGES Q.500Q.599 INTERWORKING 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
4、Q.1000Q.1099 INTERWORKING WITH SATELLITE MOBILE SYSTEMS Q.1100Q.1199 INTELLIGENT NETWORK Q.1200Q.1699 SIGNALLING 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 de
5、tails, please refer to the list of ITU-T Recommendations. Q series Supplement 48 (03/2004) i Supplement 48 to ITU-T Q-series Recommendations Guideline document for specifying API/object interface between network control and application layer Summary There are many API/Object Interface-related activi
6、ties outside of ITU-T Study Group 11 and API/Object Interface specifications are developed in them. In order to enhance the usefulness of such API/Object Interface, some common guideline may be required. This Supplement intends to clarify the guidelines that make sure the effectiveness of each API/O
7、bject Interface and facilitate the smooth introduction of it. Source Supplement 48 to ITU-T Q-series Recommendations was agreed on 12 March 2004 by ITU-T Study Group 11 (2001-2004). ii Q series Supplement 48 (03/2004) FOREWORD The International Telecommunication Union (ITU) is the United Nations spe
8、cialized 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 and issuing Recommendations on them with a view to standardizing telecommunications on
9、 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 these topics. The approval of ITU-T Recommendations is covered by the procedure laid do
10、wn 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 expression “Administration“ is used for conciseness to indicate both a telecommunication ad
11、ministration and a recognized operating agency. Compliance with this publication is voluntary. However, the publication may contain certain mandatory provisions (to ensure e.g. interoperability or applicability) and compliance with the publication is achieved when all of these mandatory provisions a
12、re met. The words “shall“ or some other obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the publication is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the poss
13、ibility that the practice or implementation of this publication may involve the use of a claimed Intellectual 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 pub
14、lication development process. As of the date of approval of this publication, ITU had not received notice of 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 ar
15、e therefore strongly urged to consult the TSB patent database. ITU 2004 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. Q series Supplement 48 (03/2004) iii CONTENTS Page 1 Scope 1 2 References. 1 2.1 Website r
16、eferences 1 2.2 Document references 1 3 Definitions 1 4 Abbreviations 1 5 Guidelines for specifying API/object interface 2 5.1 Mapping with protocol messages . 2 5.2 Modelling total process for introducing API-based application. 3 5.3 Requirement on address information 4 5.4 Requirement on release c
17、ause 5 Q series Supplement 48 (03/2004) 1 Supplement 48 to ITU-T Q-series Recommendations Guideline document for specifying API/object interface between network control and application layer 1 Scope This Supplement provides guidelines for specifying API/Object Interface in the API/Object Interface-r
18、elated activities outside of the ITU-T. It focuses on the specifications of API/Object Interface between network control and application layers, which can be referred in the Scope clause of API Reference Document d1. 2 References 2.1 Website references w1 3GPP website: http:/www.3gpp.org/ w2 Parlay
19、website: http:/www.parlay.org/ w3 ETSI website: http:/docbox.etsi.org/TISPAN/Open/OSA 2.2 Document references d1 ITU-T Q-series Recommendations Supplement 40 (2002), Technical Report: Reference document on API/object interface between network control and application layer. d2 3GPP TR 21.905, Vocabul
20、ary for 3 GPP Specifications. d3 ITU-T Recommendation E.164 (1997), The international public telecommunication numbering plan. d4 IETF RFC 1630 (1994), Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wi
21、de Web. d5 ITU-T Recommendation X.213 (2001) | ISO/IEC 8348:2002, Information technology Open Systems Interconnection Network service definition. d6 ITU-T Recommendation Q.850 (1998), Usage of cause and location in the Digital Subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN U
22、ser Part. 3 Definitions The definitions with regard to OSA follow the definitions in 3GPP vocabulary document d2. 4 Abbreviations API Application Programming Interface CAP CAMEL Application Part ISUP ISDN User Part NSAP Network Service Access Point OSA Open Service Access SDO Standards Developing Or
23、ganization URI Uniform Resource Identifier 2 Q series Supplement 48 (03/2004) 5 Guidelines for specifying API/object interface In this clause, the guidelines needed to be considered when specifying APIs are described. Each subclause covers specific subject areas to be considered. They include expect
24、ed API features to be supported for the subject area, existing specification and other information. 5.1 Mapping with protocol messages 5.1.1 Importance of mapping specification Application portability on multi-vendor environment is one of the main objects of open API technology. However, different i
25、nterpretation of the API specification may lead to that situation that an API message mapped to a protocol message “x“ in one API platform X is mapped to another protocol message “y“ in another API platform Y. Therefore, to ensure the application portability, provision of explicit mapping specificat
26、ions clarifying the mapping of API messages with protocol messages (e.g., ISUP messages) is very important. 5.1.2 Expected descriptive requirements on mapping document Any mapping description will be needed to provide the following information in order to assure the successful application portabilit
27、y in API-based developments. 1) Mapping sequence A mapping sequence should describe how the API messages are invoked by an application map to the corresponding protocol messages. An example mapping sequence diagram is shown in Figure 1. Mapping sequence templates may be developed in the future. Appl
28、icationPlatformProtocol peerAPI message AProtocol message xAPI message BProtocol message yFigure 1 Example of mapping sequence diagram 2) Parameter mapping Parameter mapping should include the detailed relation between the parameters in an API message and the parameters in the corresponding protocol
29、 message. An example of parameter mapping is shown in Table 1. Parameter mapping templates may be developed in the future. Table 1 Example of parameter mapping table API message A Protocol message x 1 Parameter A1 Parameter x1 2 Parameter A2 Parameter x2 Q series Supplement 48 (03/2004) 3 3) Other d
30、escriptive requirements In addition to the mapping sequence diagram and parameter mapping table introduced above, the following information may also be included in the mapping description: State transition model within the platform; Conditions to invoke API other than protocol messages; etc. Templat
31、es for describing these items may also be developed in the future. 5.1.3 Areas for developing mapping specification APIs being developed in SDOs may be applicable to several areas, but the importance of mapping specification may depend on the area the APIs are to be applied. Among them, the call con
32、trol area would have highest importance for the development of API mapping specification. Importance of API mapping to other areas will be studied in the future. 5.1.4 Existing mapping specifications The following activities are identified. 1) 3GPP w1 3GPP has been developing the mapping specificati
33、on related to its API works. The following documents are already developed: 3G TR 29.998-04-1: Mapping for OSA Call Control to CAP; 3G TR 29.998-04-4: Mapping for OSA Multiparty Call Control to SIP; 3G TR 29.998-05-1: Mapping for OSA User Interaction to CAP; 3G TR 29.998-05-4: Mapping for OSA User I
34、nteraction to SMS; 3G TR 29.998-06: Mapping for OSA User location to MAP; 3G TR 29.998-08: Mapping for OSA Data session Control to CAP. It also has the following plan to develop new mapping specifications: OSA PAM (Presence application development; and platform development. 5.3 Requirement on addres
35、s information 5.3.1 Importance of address-independent interface In the next generation network, several types of address information are supposed to be adopted, e.g., E.164 d3, URI d4 and NSAP d5. The API between network control function and service application should not restrict the type of addres
36、s considering the usefulness of the API in a wide area. API should be independent not only from protocols but also from address types. Therefore, parameters of API including address information should have some mechanism that can deal with each address type. 5.3.2 Expected features of API in handlin
37、g address information In order to handle various address types, the parameter that handles address information needs to meet the following requirements to ensure the availability of API: 1) Parameter for address information included in the API between network control and service application should n
38、ot have condition specific for particular type of address. The parameter should be applied to each address type without any change. 2) The length of the parameter should cover the maximum length of each address type that is anticipated as a candidate address type for the next generation network. Q s
39、eries Supplement 48 (03/2004) 5 5.3.3 Existing specification to handle address information The following activities are identified. ETSI w3. The following address types are specified in the parameter for the exchange of address information. The detail information is contained in ETSI ES 202 915-2 V1
40、.2.1. IP address (including multicast and unicast address); E.164; AESA; URL; SMTP; X.400; SIP. The specification above covers both features described in 5.3.2. 5.4 Requirement on release cause 5.4.1 Importance of protocol independent interface Some service applications want to judge how to behave a
41、ccording to the cause of release sent by terminals. Service applications may also need to send specific cause of release to terminals. APIs between network control and service application should deal with the cause of release in their parameters. Though the number or the classification of release ca
42、use are different with each protocol, the API between network control and service application, which must be protocol independent, should not be bound to a specific protocol in handling release cause. Therefore, API should deal with protocol-specific cause value without being conscious of the type o
43、f its protocol. 5.4.2 Expected features of API in handling release cause 5.4.2.1 Requirement for API in handling release cause API specification between network control and service application should be able to deal with cause of release. The parameter which contains release cause value is required
44、to be independent from each protocol. 5.4.2.2 Example solutions to meet the requirement Example solutions to the requirement in 5.4.2.1 are as follows. 1) Parameter for cause of release contains: cause values defined in each protocol; and protocol identifier, which can be omitted in a single protoco
45、l environment. 2) Parameter for cause of release contains newly defined common cause of release, which is protocol independent and can cover all protocol-dependent cause values. 3) Parameter for cause of release contains the limited number of newly defined cause of release, which is protocol indepen
46、dent and needs to be mapped to each protocol-dependent cause value. In example 1, the application should know which protocol is used in network control. It may cause complexity if the application is protocol independent. Example 2 needs significant effort to define new release causes to cover all th
47、e identified protocols; continuous enhancement is also necessary 6 Q series Supplement 48 (03/2004) to cover newly specified cause values in each protocol. Example 3 may be easy from the aspect of developing API specification, but needs mapping work from newly developed cause to release cause specif
48、ied in each protocol. These are just example solutions to the requirement and to be listed only for the better understanding of the requirement. Some other solutions may also be possible and this Supplement does not intend to recommend either of the solutions. 5.4.3 Existing release cause specificat
49、ions The following activities are identified. ETSI w3. In ETSI ES 202 915-4-2 V1.2.1, the parameter for release cause that contains Value and Location is defined. It just refers to ITU-T Rec. Q.850 to aid understanding for detail Value and Location. It does not define any new common cause of release and no specific codes are given. Therefore, this specification in ETSI may be categorized under item 2 in 5.4.2.2. In ETSI ES 202 915-4-3 V1.2.1, thirteen cause values a
