ETSI TS 102 142-2003 Services and Protocols for Advanced Networks (SPAN) MTP SCCP SSCOP and SIGTRAN (Message of SS7 over IP) Message transfer part 3 User Adaptation layer (M3UA) (E_1.pdf

1、ETSI TS 102 142 1.1.1 (2003-05) Technical Specificafion Services and Protocols for Advanced Networks (SPAN); MTP/SCCP/SSCOP and SIGTRAN (Message of SS7 over IP); Message transfer part 3 User Adaptation layer (M3UA) Endorsement of RFC 3332 (2002), modified 2 ETSI TS 102 142 VI .I .I (2003-05) Referen

2、ce DTSISPAN-I30263 Keywords MJUA, MTP, SCCP, SIGTRAN, SS7, endorsement 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

3、 7803/88 Important notice Individual copies of the present 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

4、 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 document may be subject to revision or change o

5、f status. Information on the current status of this and other 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 permi

6、ssion. The copyright and the foregoing restriction extend to 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

7、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 3 ETSI TS 102 142 VI .I .I (2003-05) Contents Intellectual Property Rights . .4 Foreword . 4 Endorsement not

8、ice . .4 Introduction . .4 1 2 3 3.1 3.2 4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 5 5.1 5.2 5.3 5.4 6 Scope 5 References . .5 Definitions and abbreviations. . .5 . 5 . 6 6 Transport protocol . 6 SCTP considerations . . 6 National options . 6 Application Server mode . 6 Application Server state handlin . .

9、7 Dynamic registration . Message distribution to t erver . 7 7 Receipt of unrecognized messages . Considerations applicable to M3UA . .7 National options . 7 Dynamic registration 7 Message distribution to the Application Server M3UA procedures 7 De Ab General considerations applicable to transport o

10、f Signalling System No. 7 over IP . .6 7 Modifications to RFC 3332 7 History 11 ETSI 4 ETSI TS 102 142 VI .I .I (2003-05) 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, i

11、f any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: “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

12、 on the ETSI Web server (5). All published ETSI deliverables shall include information which directs the reader to the above source of information. Foreword This Technical Specification (TS) has been produced by ETSI Technical Committee Services and Protocols for Advanced Networks (SPAN). Endorsemen

13、t notice The Elements of the Internet Engineering Task Force Request for Comments RFC 3332 i apply, with the following modifications. I n t rod uct ion The present document records the changes to the Internet Engineering Task Force (IETF) RFC 3332 i. This RFC specifies an Internet standard track pro

14、tocol for the transport of Signalling Systems N0.7 (SS7) information over IP using the Stream Control Transmission Protocol. ETSI 5 ETSI TS 102 142 VI .I .I (2003-05) 1 Scope The present document specifies the requirements for the MTP3 User Adaptation layer (M3UA), when used in conjunction with the

15、Stream Control Transmission Protocol (SCTP) for the transport of the Signalling System No.7 Message Transport Part 3 (MTP3) information over the Internet Protocol (IP). The document endorses and constrains where relevant the SIGTRAN (IETF) RFC 3332 i of M3UA. 2 Re fe re nces The following documents

16、contain provisions which, through reference in this text, constitute provisions of the present document. References are either specific (identified 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-sp

17、ecific reference, the latest version applies. Referenced documents which are not found to be publicly available in the expected location might be found at p. il IETF RFC 3332 (2002): “Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)“, G. Sidebottom, K. Morneault

18、, J. Pastor-Balbas. ETSI TS 102 144: “Services and Protocols for Advanced Networks (SPAN); MTP/SCCP/SSCOP and SIGTRAN; SCTP Endorsement of RFC 2960 and RFC 3309, modified“. ETSI EN 300 008-1 : “Integrated Services Digital Network (ISDN); Signalling System N0.7; Message Transfer Part (MTP) to support

19、 international interconnection; Part 1 : Protocol specification ITU-T Recommendations Q.701, Q.702, Q.703, Q.704, Q.705, Q.706, Q.707 and Q.708 modified“. ITU-T Recommendation Q.704: “Specifications of Signalling System No. 7, Message Transfer Part, Signalling network functions and messages“. ETSI E

20、G 201 693: “Integrated Services Digital Network (ISDN); Signalling System No.7; Master list of codepoints“. ETSI TS 102 141: “Services and Protocols for Advanced Networks (SPAN); MTP/SCCP/SSCOP and SIGTRAN (Transport of SS7 over IP); Message transfer part 2 User Adaptation layer (M2UA) Endorsement o

21、f RFC 333 1 (2002), modified“. ETSI TS 102 143: “Services and Protocols for Advanced Networks (SPAN); MTP/SCCP/SSCOP and SIGTRAN (Transport of SS7 over IP); Signalling connection control part User Adaptation layer (SUA) Endorsement of SIGTRAN-SUA-14 (December 2002), modified“. 21 31 41 51 61 71 3 De

22、finitions and abbreviations 3.1 De fi nit ions For the purposes of the present document, the following terms and definitions apply: example 1: text used to clarisl abstract rules by applying them literally ETSI 6 3.2 Abbreviations ETSI TS 102 142 VI .I .I (2003-05) For the purposes of the present do

23、cument, the following abbreviations apply: AS ASP BEAT BEAT Ack DAUD DRST DUNA DUPU IANA IETF IP RFC SCTP SG SGP ss7 TCP Application Server AS Process heartBEAT heartBEAT Acknowledgement Destination state AUDit Destination ReSTricted Destination UNAvailable Destination User Part Unavailable Internet

24、 Assigned Numbers Authority Internet Engineering Task Force Internet Protocol Request For Comment Stream Control Transmission Protocol Signalling Gateway SG Process Signalling System Number 7 Transmission Control Protocol 4 General considerations applicable to transport of Signalling System No. 7 ov

25、er IP The elements of SIGTRAN adaptation layers apply with the following exceptions and restrictions. The considerations in this clause are common to TS 102 141 6, the present document and TS 102 143 7. 4.1 Transport protocol The protocol underlying the adaptation layer for transport of SS No.7 sign

26、alling information in IP networks shall be SCTP. 4.2 SCTP cons id erat ions The SCTP used shall conform to TS 102 144 2. The SCTP payload protocol identifier for messages pertaining to an adaptation layer shall be the one assigned by IANA for that layer. Adaptation layer messages received with neith

27、er the IANA payload protocol identifier nor payload protocol identifier equal to O shall be silently discarded. Unordered user messages shall not be used. 4.3 National options No national options excluded by ETSI standards shall apply to the present document. 4.4 Application Server mode The Broadcas

28、t mode shall not be used. 4.5 Application Server state handling If multiple Application Server Processes (ASPS) are used within the AS, the AS shall be considered active when the first ASP becomes active, and shall remain active until the last ASP becomes inactive. ETSI 7 ETSI TS 102 142 VI .I .I (2

29、003-05) 4.6 Dynamic reg ist ra ti on Dynamic registration shall not be used for configuration management. The configuration of the system shall be modified only by the management system, and not by the protocol itself. 4.7 Message distri bution to the Application Server The key to enable messages to

30、 be distributed to the appropriate AS shall have a granularity no smaller than is allowed by the network management messages appropriate to that layer. 4.8 Receipt of unrecognized messages If a message with an unrecognized message class is received, a Management Error message shall be returned with

31、Error Code “Unsupported Message Class“. 5 Considerations applicable to M3UA 5.1 National options No national options excluded by EN 300 008-1 3 shall apply to the present document. 5.2 Dynamic reg ist ra ti on Dynamic registration of Routing Keys shall not be used for configuration management. The c

32、onfiguration of the system shall be modified only by the management system, and not by the protocol itself. 5.3 Message distri bution to the Application Server The Routing Key to enable messages to be distributed to the appropriate AS shall have a granularity no smaller than Point Code. 5.4 M3UA pro

33、cedures The M3UA procedures shall be as defined in RFC 3332 i augmented by ITU-T Recommendation Q.704 4 as modified by EN 300 008-1 3, except where otherwise defined below. 6 Modifications to RFC 3332 Modifications to RFC 3332 i are listed according to the sections and subsections of RFC 3332 i. Sub

34、section 1.3.1 Protocol Architecture SCTP shall be used as the transport protocol for M3UA. TCP shall not be used as the transport protocol for M3UA. Subsection 1.3.2.1 Support for the Transport of MTP3-User Messages The maximum signalling information field size shall be 272 octets. Subsection 1.3.2.

35、3 Interworking with MTP3 Network Management Functions M3UA at the ASP shall be enabled to initiate audit of availability of remote SS7 destinations. Restricted or congested states should not be audited. ETSI 8 ETSI TS 102 142 VI .I .I (2003-05) M3UA at the ASP shall be enabled to indicate to SG that

36、 the M3UA layer itself or the ASP or the ASPS host is congested. Subsection 1.4.1 Signalling Point Code Representation M3UA shall not allow a single point code to represent both the SG and an application server. Alias point codes are not required. Signalling links between mated SGs are outside the s

37、cope of this specification. Subsection 1.4.2.1 Overview An ASP can belong to one or more application server. Subsection 1.4.2.4 Message Distribution at the ASP The behaviour if no active ASP is available is a nodal function. The default treatment if no matching routing key entry is found for incomin

38、g SS7 message is implementation dependent, but layer management shall be informed if the received message is discarded. Subsection 1.4.6 Congestion Management How M3UA layer is informed of local and IP network congestion is implementation dependent. However, it is mandatory that the M3UA layer is in

39、formed. When a SG determines that the transport of SS7 messages to a signalling point is encountering congestion, the SG shall trigger SS7 MTP3 TFC management messages to originating SS7 nodes, per the congestion procedures of EN 300 008-1 3 and ITU-T Recommendation Q.704 4. Triggering of SS7 MTP3 m

40、anagement messages from a SG is mandatory. The means of doing this is implementation dependent. The M3UA layer at an ASP shall indicate local congestion to an M3UA peer via an implementation dependent method. When the SG receives an SCON from an ASP and determines that a SP is encountering congestio

41、n, it shall trigger SS7 MTP3 TFC messages to concerned SS7 destinations according to congestion procedures of EN 300 008-1 3 and ITU-T Recommendation Q.704 4. The receiving node shall be able to detect local congestion and inform the transmitting node of this, by whatever means. Subsection 1.4.7 SCT

42、P Stream Mapping SCTP stream mapping is implementation dependent, but any MSUs requiring sequenced delivery with respect to each other. shall be sent over the same stream. Subsection 1.4.8 ClientBerver Model The SGP shall be able to support SCTP server operation and the ASP shall be able to support

43、SCTP client operation. Support of both SCTP client and SCTP server operation at the ASP or SGP is optional. Subsection 3.4.1 Destination Unavailable (DUNA) The SG may suppress the sending of subsequent “response“ DUNA messages regarding a certain unreachable SS7 destination for T8 period to give the

44、 remote side time to react. See ITU-T Recommendation Q.704 4 for T8. It is optional to send an affected point code parameter with more than one affected DPC in it, but the ability to receive this is mandatory. Subsection 3.4.3 Destination state Audit (DAUD) Destination state Audit (DAUD), shall be s

45、ent from ASP to SGP to audit the availability of SS7 routes from SG to one or more affected destinations. The frequency of the route test messages shall be as described for T10. See ITU-T Recommendation Q.704 4 for T10. DAUD shall not be sent to audit the congestion or restricted state. ETSI 9 ETSI

46、TS 102 142 VI .I .I (2003-05) Subsection 3.4.4 Signalling Congestion The SCON message can be sent from an SGP to all concerned ASPS to indicate that a SG has determined that there is congestion in the SS7 network to one or more destinations. The receiving node shall be able to detect local congestio

47、n and inform the transmitting node of this, by whatever means. An SCON can be sent to ASP in response to DATA message, as appropriate. Multiple congestion levels are not supported. SCONS may be sent from the M3UA layer on ASP to M3UA peer indicating that the M3UA layer or ASP is congested. The sendi

48、ng of an SCON message shall not be delayed in order to collect a number of affected DPCs. Multiple affected DPCs may be included, as long as this does not delay the sending of the SCON message. Subsection 3.4.5 Destination User Part Unavailable (DUPU) The values here shall align with the MTP3 User P

49、art Unavailable message and service indicator. Additional service indicator values may also be required. See EG 201 693 5. Subsection 3.4.6 Destination Restricted (DRST) Destination Restricted (DRST), shall not be sent. If DRST is received, it shall be discarded. Subsection 3.5.5 Heartbeat (BEAT) M3UA BEAT shall not be used. Subsection 3.5.6 Heartbeat Acknowledgement (BEAT Ack) M3UA shall return a BEAT ACK, if a BEAT is received. Subsection 3.8.1 Error An “unexpected message“ error cause may be sent if a defined and recognized