ITU-T Q 765 5-2004 Signalling system No 7 C Application transport mechanism Bearer Independent Call Control (BICC) SERIES Q SWITCHING AND SIGNALLING Specifications of Signalling Syo .pdf

1、 INTERNATIONAL TELECOMMUNICATION UNION ITU-T Q.765.5TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (04/2004) SERIES Q: SWITCHING AND SIGNALLING Specifications of Signalling System No. 7 ISDN user partSignalling system No. 7 Application transport mechanism: Bearer Independent Call Control (BICC) ITU

2、-T Recommendation Q.765.5 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 SY

3、STEMS Q.100Q.119 SPECIFICATIONS 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 General Q.700 Message transfer part (MTP) Q.701Q.709 Signalling connection control p

4、art (SCCP) Q.711Q.719 Telephone user part (TUP) Q.720Q.729 ISDN supplementary services Q.730Q.739 Data user part Q.740Q.749 Signalling System No. 7 management Q.750Q.759 ISDN user part Q.760Q.769 Transaction capabilities application part Q.770Q.779 Test specification Q.780Q.799 Q3 INTERFACE Q.800Q.8

5、49 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 SIGNALLING REQUIREMENTS AND PROTOCOLS FOR IMT-2000 Q.1700Q.1799 SPECIFICATIONS OF SIGNALLING RELATED TO BEARER IND

6、EPENDENT CALL CONTROL (BICC) Q.1900Q.1999 BROADBAND ISDN Q.2000Q.2999 For further details, please refer to the list of ITU-T Recommendations. ITU-T Rec. Q.765.5 (04/2004) i ITU-T Recommendation Q.765.5 Signalling system No. 7 Application transport mechanism: Bearer Independent Call Control (BICC) Su

7、mmary This Recommendation describes the extensions required for the transport of bearer-related information associated with the Bearer Independent Call Control (BICC) as defined in ITU-T Rec. Q.1902.1. The BICC is used to manage the call control instance that has been separated from the bearer contr

8、ol instance. The BICC needs to transport bearer-related information between call control instances. The Application Transport Mechanism (APM) (see ITU-T Recs Q.1902.5 and Q.1902.1) will be used for this purpose. This Recommendation specifies the APM-user to support the transport of the bearer-relate

9、d information for the BICC. Source ITU-T Recommendation Q.765.5 was approved on 13 April 2004 by ITU-T Study Group 11 (2001-2004) under the ITU-T Recommendation A.8 procedure. ii ITU-T Rec. Q.765.5 (04/2004) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized a

10、gency 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 a worldwi

11、de 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 down in WTSA

12、 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 Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunication administr

13、ation and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure e.g. interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions

14、 are 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 Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the

15、 possibility that the practice or implementation of this Recommendation 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

16、 the Recommendation development process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementors are cautioned that this may not represent the latest i

17、nformation and are 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. ITU-T Rec. Q.765.5 (04/2004) iii CONTENTS Page 1 Scope 1 2 References. 1

18、3 Definitions 1 4 Abbreviations 2 5 Conventions 3 6 Recommendation structure . 3 7 Modelling 4 7.1 Network model . 4 7.2 Specification model 5 8 BICC application process functions . 8 8.1 Introduction 8 8.2 Primitive interface (AP-BICC SACF) 8 8.3 Primitive contents. 9 9 Single Association Control F

19、unction (SACF) BICC SACF 9 9.1 Introduction 9 9.2 Information flows related to messages sent by the node 10 9.3 Information flows related to messages received by the node. 10 10 BAT ASE 10 10.1 Primitive interface 10 10.2 Signalling procedures . 11 10.3 Primitive contents. 11 11 BICC Transport Forma

20、ts and codes of application data 12 11.1 Encapsulated application information 12 11.2 Application context identifier. 27 ITU-T Rec. Q.765.5 (04/2004) 1 ITU-T Recommendation Q.765.5 Signalling system No. 7 Application transport mechanism: Bearer Independent Call Control (BICC) 1 Scope This Recommenda

21、tion describes the extensions required for the transport of bearer-related information associated with the Bearer Independent Call Control (BICC) 3. The BICC is used to manage the call control instance that has been separated from the bearer control instance. The BICC needs to transport bearer-relat

22、ed information between call control instances. The Application Transport Mechanism (see 1 and 3) will be used for this purpose. This Recommendation specifies the APM-user to support the transport of the bearer-related information for the BICC. 2 References The following ITU-T Recommendations and oth

23、er references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged

24、 to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document

25、, the status of a Recommendation. 1 ITU-T Recommendation Q.1902.5 (2001), Bearer Independent Call Control protocol (Capability Set 2): Exceptions to the application transport mechanism in the context of BICC. 2 ITU-T Recommendation Q.1400 (1993), Architecture framework for the development of signall

26、ing and OA parameters; identifiers; information elements; methods/functions. Example: Backbone Network Connection Identifier information element. 2) For the name and the type of a service primitive, the following applies: the name is capitalized; the type is separated from the name by “.“ Example: B

27、ICC_Data.request primitive. 3) The definition of a parameter value is written in italics and is put between quotation marks. Example: “BAT ASE“. 6 Recommendation structure The description of the BICC procedures in this Recommendation is structured according to the model described in 7.2. The descrip

28、tion is thus divided into two main parts: Protocol functions. Non-protocol functions, i.e., exchange nodal functions; this is referred to as the “Application Process“. This Recommendation describes only the part of the total Application Process and Protocol functions in the exchange that relates to

29、NNI enhancements for the support of the transport of bearer-related information for BICC. 4 ITU-T Rec. Q.765.5 (04/2004) The signalling association is subdivided into three parts: Bearer Association Transport (BAT ASE), Application Transport Mechanism (APM ASE) and BICC ASE. These are coordinated by

30、 the Single Association Control Function (SACF). The Application Process (AP) contains all Call Control functions; however, this Recommendation will only describe the enhancements required to support the Bearer Independent Call Control. The Application Process relevant BICC functionality can be foun

31、d in 3. The service primitive technique, used to define the ASEs and the SACF specific to the applications signalling needs is a way of describing how the services offered by an ASE, or SACF, the provider of (a set) of service(s), can be accessed by the user of the service(s), the SACF or the Applic

32、ation Process (AP), respectively. The service primitive interface is a conceptual interface and is not a testable or accessible interface. It is a descriptive tool. The use of service primitives at an interface does not imply any particular implementation of that interface, nor does it imply that an

33、 implementation must conform to that particular service primitive interface to provide the stated service. All conformance to the BICC specifications is based on the external behaviour at a node, i.e., on the generation of the correct message structure (as specified in 1 and 3)/operation structure (

34、as specified in this Recommendation) and in the proper sequence (as specified in 3 and in this Recommendation). The structure and examples of its usage are illustrated in 7.2. The relationship between the existing ISDN network functionality and the Application Transport Mechanism service provided by

35、 the public NNI (BICC) is described as a network model in 7.1. 7 Modelling The models described in this clause introduce concepts and terminology used in this specification of the BICC use of the capability of the Application Transport Mechanism (APM). 7.1 Network model EXC A-SNPINEXCB-SNPANFigure 1

36、/Q.765.5 BICC network topology This clause provides an illustration of the use of the APM in the support of BICC. The APM provides the means to transport BICC specific information needed for the establishment of bearer connections across a core bearer network and the binding between the call control

37、 instance and the bearer control instance(s). Figure 1 shows an example of a network topology for the BICC (additional configurations are possible that include CMNs). A-SN is the incoming SN and B-SN is the outgoing SN. The SN exchanges are connected to other network exchanges (EXC) which may be ISD

38、N exchanges within the existing narrow-band PSTN network with an ISUP interface to the SN or other SNs with a BICC interface. The Public Initiating Node (PIN) and Public Addressed Node (PAN) concept is introduced in 1 to assist in the description of the APM. The PIN represents the point in the netwo

39、rk where an APM-user, in this case BICC, wishes to initiate communications towards a peer APM-user. Since ITU-T Rec. Q.765.5 (04/2004) 5 the APM implicit addressing mechanism (see 1) is used for the BICC, the Public Addressed Node (PAN) is the next node in the call path supporting the BAT-ASE. The c

40、all flow examples that illustrate the use of the APM may be found in ITU-T Rec. Q.1902.1 3. 7.2 Specification model 7.2.1 Introduction The model used to structure the description of BICC application procedures is based on the OSI Application Layer Structure (ALS) model (see 2). This clause presents

41、the model, gives a general description of its operation and shows the generalized model for the “Exchange Application Process“ for the support of BICC. It shows how the application makes use of the Application Transport Mechanism (APM) which is described in detail in 1 and 3. 7.2.2 General model The

42、 generalized model for the BICC Process is shown in Figure 2. This figure does not represent the situation at any specific point during a call but, instead, shows the full picture of the architecture. The specific application of this model is discussed below. Figure 2 shows the primitive interfaces

43、between the functional blocks, as used in the body of this Recommendation for calls using BICC. Figure 2/Q.765.5 BICC specification model With respect to Figure 2, all functions also have an interface to a “Maintenance application“; this is not defined as a formal primitive interface. The term “Exch

44、ange Application Process“ is used to describe all the Application functionality in an exchange. BICC is a part of the Exchange Application Process. Thus the BICC Nodal functions 6 ITU-T Rec. Q.765.5 (04/2004) shown on the model are referred to as the BICC Application Process functions in the body of

45、 this Recommendation. The APM ASE, and EH ASE are described in detail in 1 and 3. The BICC AEI and BICC ASE are similar to the ISUP AEI and ISUP ASE. The ISUP AEI and ISUP ASE are described in detail in 1. NOTE Further clarifications about the BICC protocol modelling and relationships between BICC A

46、EI, BICC ASE and ISUP AEI, ISUP ASE are given in 3. The BAT ASE is a user of the services offered by the APM ASE. It is responsible for preparing the bearer-related information in a form that can be transported by the public Application Transport Mechanism (APM). The SACF has the responsibility of c

47、oordinating the flow of primitives between its interfaces in the appropriate manner. To handle any particular BICC function, the Exchange Application Process creates an instance of the required BICC Nodal functions. The AP will create instances, as required, of the BICC AEI. The Network Interface (N

48、I) function exists to distribute messages received via the Signalling Transport Converter to the appropriate instance of the BICC AEI. There is only one instance of the NI in an exchange. The NI is described in detail in 1 and 3. The SAO contained in the BICC AE is one of the following types: a) Pub

49、lic Initiating Node This contains: Outgoing BICC ASE, Initiating APM ASE, Initiating EH ASE, Outgoing BAT ASE and BICC SACF. b) Public Addressed Node This contains: Incoming BICC ASE, Addressed APM ASE, Addressed EH ASE, Incoming BAT ASE and BICC SACF. 7.2.3 Signalling Flows Figures 3 and 4 illustrate the dynamic primitive flows for a BICC call over the BICC for the case that a call control message is coincident with the application information flow. Figure 3 shows the case when a messa