1、 ETSI TS 102 332 V1.1.1 (2004-06)Technical Specification Telecommunications and Internet converged Services andProtocols for Advanced Networking (TISPAN);Bachauling of ISDN Q.921 (Transport of DSS1 over IP);ISDN Q.921-User Adaptation Layer (IUA)Endorsement of RFC 3057 (2001), modifiedETSI ETSI TS 10
2、2 332 V1.1.1 (2004-06) 2 Reference DTS/TISPAN-03011-Tech Keywords endorsement, SCTP, SIGTRAN, user, adaptation, protocol 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 lucrat
3、if enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice Individual 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 i
4、n contents between such versions, the reference version is the Portable Document 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
5、document may be subject to revision or change of status. Information on the current 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, send your comment to: editoretsi.org Copyright Notification No part may b
6、e reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2004. All rights reserved. DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of it
7、s Members. 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 TS 102 332 V1.1.1 (2004-06) 3 Intellectual Property Ri
8、ghts IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining 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); Essentia
9、l, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. 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 bee
10、n 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 updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Specification (TS) has been produced by ETSI Te
11、chnical Committee Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN). Introduction The present document records the changes to the Internet Engineering Task Force (IETF) RFC 3057 1. This RFC specifies the ISDN Q.921-User Adaptation Layer (IUA), which is
12、 using the services of the Stream Control Transmission Protocol (SCTP), the common transport protocol used by all SIGTRAN adaptation layers. ETSI ETSI TS 102 332 V1.1.1 (2004-06) 4 1 Scope The present document specifies the requirements for the ISDN Q.921-User Adaptation Layer (IUA) when used in con
13、junction with the SCTP layer for the transport of Digitals Subscriber Signalling System No.1 (DSS1) messages over the Internet Protocol (IP). The present document endorses and constrains where relevant the IUA defined in RFC 3057 1. 2 References The following documents contain provisions which, thro
14、ugh reference in this text, constitute provisions of the present document. References are either specific (identified by date of publication 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
15、 version applies. Referenced documents which are not found to be publicly available in the expected location might be found at http:/docbox.etsi.org/Reference. 1 IETF RFC 3057 (2001): “ISDN Q.921-User Adaptation Layer“. 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present
16、document, the following terms and definitions apply: example 1: text used to clarify abstract rules by applying them literally 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: ASPAC ASP Active ASPDN ASP DownASPIA ASP Inactive ASPM ASP State Maintenance A
17、SPSM Application Server Process State Maintenance ASPUP ASP Up BEAT Heartbeat ERR Error FAS Facility Associated Signalling IP Internet ProtocolIUA ISDN Q.921-User Adaptation Layer NTFY Notify QPTM Q.921/Q.931 Boundary Primitives Transport RFC Request For Comment SCTP Stream Control Transmission Prot
18、ocol ETSI ETSI TS 102 332 V1.1.1 (2004-06) 5 4 Endorsement notice The Elements of the Internet Engineering Task Force Request For Comments RFC 3057 1 apply with the following modifications. IUA protocol considerations 1.1 Scope Only Facility Associated Signalling (FAS) shall be supported. 1.2 Termin
19、ology The interface id type shall be limited to a 16 bit integer. Interface Identifier parameter: only the integer format shall be supported. 1.3.1 Example - SG to MGC The SCTP shall be used as the underlying reliable protocol. 1.3.3 Signalling Network Architecture 5thparagraph: Stable calls shall n
20、ot be lost under failure or isolation of a particular ASP. 1.3.4 ASP Fail-over Model and Terminology 7thparagraph: In the process of fail-over or fail-back, stable calls shall not be lost. 1.5.3 SCTP Stream Management The IUA layers shall ensure proper management of SCTP streams. A separate stream s
21、hall be used for each D channel. 1.5.4 Seamless Network Management Interworking If an SCTP association fails, the IUA layer on the ASP side (S12MGC) shall generate Release primitives to take the data links out-of-service. 1.5.5 Congestion Management The SCTP layer shall detect congestion and shall c
22、ontrol/manage the congestion (e.g. Slow-Start and Congestion Avoidance). 3.1.2 Message Classes and Types Following message classes shall be supported: 0 Management (MGMT) message IUA 3 ASP State Maintenance (ASPM) Messages IUA 4 ASP Traffic Maintenance (ASPTM) Message IUA 5 Q.921/Q.931 Boundary Prim
23、itives Transport (QPTM) Messages (IUA) The Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages shall be supported. Application Server Process State Maintenance (ASPSM) messages shall be supported. Application Server Process Traffic Maintenance (ASPTM) messages shall be supported. Management (M
24、GMT) Messages shall be supported. ETSI ETSI TS 102 332 V1.1.1 (2004-06) 6 3.1.3 Reserved The reserved field shall be set to all “0“ s by the sender and ignored by the receiver. 3.1.5 Variable Length Parameter Format Not more than 3 bytes shall be padded. 3.2 IUA Message Header The interface identifi
25、er parameter format shall be Integer. Text format is not yet supported. The interfaceId can only have values between 1 - 65 535 (16 bits). 3.3.1.1 Establish Messages (Request, Indication, Confirmation) When the MGC sends an IUA Establish message, the MGC shall start a timer t-establish. The MGC shal
26、l continue to request the establishment of the data link on a periodic basis until the desired state is achieved. 3.3.1.2 Release Messages (Request, Indication, Confirmation) The MGC shall resend the Release Request message, if a response to the Release Request is not received. 3.3.2.1 ASP Up (ASPUP
27、) INFO string shall not be used to carry ASCII characters. 3.3.2.2 ASP Up Ack INFO string shall not be used to carry ASCII characters. 3.3.2.3 ASP Down (ASPDN) INFO string shall not be used to carry ASCII characters. 3.3.2.4 APS Down AckINFO string shall not be used to carry ASCII characters. 3.3.2.
28、5 ASP Active (ASPAC) The interface identifier shall be coded as Integer. 3.3.2.7 ASP Inactive (ASPIA) The interface identifier shall be coded as Integer. 3.3.2.9 Heartbeat (BEAT) Heartbeat message shall not be used in IUA, as IUA runs over SCTP transport which has its own Heartbeat. 3.3.3.1 Error (E
29、RR) The “Unexpected Message“ error shall be sent by an ASP (S12MGC) if it received an QPTM message from an SG while it was in the inactive state. The Diagnostic information shall not be used. ETSI ETSI TS 102 332 V1.1.1 (2004-06) 7 3.3.3.2 Notify (NTFY) The interface identifier shall be coded as Int
30、eger. The text formatted Interface identifier is not supported. The interface id type is limited to a 16 bit integer. INFO string shall not be used to carry ASCII characters. 4.2.1 Layer Management primitives procedures 5thparagraph: The M-NOTIFY indication and M-ERROR indication shall also be sent
31、to Layer Management based on local IUA events. 4.2.2 Receipt of IUA Peer Management messages 2ndparagraph: The M-NOTIFY indication and M-ERROR indication shall also be sent to Layer Management based on local IUA events. 4.3.2 ASPM procedures for primitives Last paragraph: At an ASP (S12MGC), the Lay
32、er Management shall try to re-establish the SCTP association using M-SCTP ESTABLISH request primitive. 4.3.3.1 ASP Up 4thparagraph: If the ASP does not receive a response from the SG, or an ASP-Down is received, the ASP shall resend ASP-Up messages every 2 seconds until it receives an ASP-Up Ack mes
33、sage from the SG. The ASP shall decide to reduce the frequency (say to every 5 seconds) if an ASP-Up Ack is not received after a few tries. 4.3.3.2 ASP Down 5thparagraph: If the ASP does not receive a response from the SG, the ASP shall send ASP-Down messages every 2 s until it receives a ASP-Down m
34、essage from the SG or the SCTP association goes down. The ASP shall reduce the frequency (say to every 5 s) if an ASP-Down is not received after a few tries. 4.3.3.7 Heartbeat The Heartbeat procedure is not supported by the ASP, as operating is over SCTP. ETSI ETSI TS 102 332 V1.1.1 (2004-06) 8 Annex A (informative): Bibliography IETF RFC 2960 (2000): “Stream Control Transmission Protocol“. ETSI ETSI TS 102 332 V1.1.1 (2004-06) 9 History Document history V1.1.1 June 2004 Publication
