ETSI TS 102 141-2003 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) .pdf

1、ETSI TS 102 141 1.1.1 (2003-05) Technical Specificafion 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 of RFC 3331 (2002), modified 2 ETSI TS 102 141 V1.l.l (2003-05) Referen

2、ce DTSISPAN-I30262 Keywords M2UA, MTP, SCCP, SS7, SIGTRAN, 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 141 V1.l.l (2003-05) Contents Intellectual Property Rights . .4 Foreword . 4 Endorsement notic

8、e . .4 Introduction . .4 1 2 3 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 5.5 6 Scope 5 References . .5 Abbreviations .5 General considerations applicable to transport of Signalling System No.7 over IP. . .6 Transport protocol . 6 SCTP considerations . . 6 National options . . 6 Application

9、 Server mod . 6 Application Server state g . 7 Dynamic registration . . 7 Message distribution to the Application Server. Receipt of unrecognized messages Considerations applicable to M2UA . .7 M2UA procedures . . 7 National options . 7 Dynamic registration . . 7 Message distribution to the Ap . 7 .

10、 7 . 7 Using of the terms MGC (Media Gateway Controller) and ASP (Application Server process) 7 Modifications to RFC 333 1 . .8 History . .15 ETSI 4 ETSI TS 102 141 V1.l.l (2003-05) Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to

11、 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 (7PRs); Essential, orpotentially Essential, IPRs notlJied to ETSI in respect ofETSI standards“, which is avail

12、able from the ETSI Secretariat. Latest updates are available 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 Ser

13、vices and Protocols for Advanced Networks (SPAN). Endorsement notice The elements of Internet Engineering Task Force Request for Comments RFC 333 1 apply, with the following modifications. Introd U ction The present document records the changes to the Internet Engineering Task Force (IETF) RFC 333 1

14、 2 document. RFC 333 1 2 specifies an Internet standard track protocol for the backhauling of Signalling Systems N0.7 (SS7) Message Transfer Part 2 (SS7 MTP2) User signalling messages over IP using the Stream Control Transmission Protocol (SCTP) (see RFC 333 1 2). ETSI 5 ETSI TS 102 141 V1.l.l (2003

15、-05) 1 Scope The present document specifies the requirements for the MTP2 User Adaptation layer (M2UA), when used in conjunction with the Stream Control Transmission Protocol (SCTP) for the transport of the Signalling System N0.7 (SS7) Message Transport Part 3 (MTP3) messages over the Internet Proto

16、col (IP). The document endorses and constrains where relevant the SIGTRAN (IETF) RFC 333 1 2 of M2UA. 2 Re fe re nces The following documents contain provisions which, through reference in this text, constitute provisions of the present document. References are either specific (identified by date of

17、 publication andor edition number or version number) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the latest version applies. Referenced documents which are not found to be publicly available in the expected location might be found at p.

18、 il ETSI EN 300 008-1 : “Integrated Services Digital Network (ISDN); Signalling System N0.7; Message Transfer Part (MTP) to support international interconnection; Part 1 : Protocol specification ITU-T Recommendations Q.701 (1993), Q.702 (1988), Q.703 to Q.706 (1993), modified l. IETF RFC 3331: “Sign

19、aling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer“. 21 NOTE: At- 31 ITU-T Recommendation Q.70 1 : “Functional description of the message transfer part (MTP) of Signalling System No. 7“. ITU-T Recommendation Q.702: “Signalling data link“. ITU-T Recommendation Q.703 : “Signal

20、ling link“. ETSI TS 102 142: “Services and Protocols for Advanced Networks (SPAN); MTP/SCCP/SSCOP and SIGTRAN (Messag of SS7 over IP); Message transfer part 3 User Adaptation layer (M3UA) Endorsement of RFC 3332 (2002), modified“. ETSI TS 102 143: “Services and Protocols for Advanced Networks (SPAN)

21、; 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“. ETSI TS 102 144: “Services and Protocols for Advanced Networks (SPAN); MTP/SCCP/SSCOP and SIGTRAN (Transport of SS7 over I

22、P); Stream Control Transmission Protocol (SCTP) Endorsement of RFC 2960 and RFC 3309, modified“. 41 51 61 71 SI 3 Abbreviations For the purposes of the present document, the following abbreviations apply: AS Application Server ASP Application Server Process ASPAC ASP Active ASPIA ASP InActive ETSI 6

23、 ETSI TS 102 141 V1.l.l (2003-05) ASPSM ASPTM BEAT BEAT ACK DEREG REQ DEREG RSP ERR IANA IETF IIM IP M2UA MAUP Application Server Process State Maintenance ASP Traffic Management heartBEAT heartBEAT ACK DE-REGistration REQuest DE-REGistration Re SPonse ERroR Internet Assigned Numbers Authority Inter

24、net Engineering Task Force Interface Identifier Management Internet Protocol Message transfer part level 2 User Adaptation layer MAUP NOTE: Is used in RFC for MTP2 User adaption. MGC MTP MTP2 MTP3 NTFY REG REQ REG RSP SCTP SG SGP ss7 Media Gateway Controller Message Transfer Part Message Transfer Pa

25、rt level 2, the signalling data link layer over SS7 Message Transfer Part level 3, the signalling network layer over SS7 NoTiFY REGistration REQuest REGistration ReSPonse Stream Control Transmission Protocol Signalling Gateway Signalling Gateway Process Signalling System Number 7 4 General considera

26、tions applicable to transport of Signalling System No.7 over IP The elements of SIGTRAN adaptation layers apply with the following exceptions and restrictions. The considerations in this clause are common to the present document, TS 102 142 6 and TS 102 143 7. 4.1 Transport protocol The protocol und

27、erlying the adaptation layer for transport of SS No.7 signalling information in IP networks shall be SCTP. 4.2 SCTP cons id erat ions The SCTP used shall conform to TS 102 144 SI. The SCTP payload protocol identifier for messages pertaining to an adaptation layer shall be the one assigned by IANA fo

28、r that layer. Adaptation layer messages received with neither 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

29、 present document. 4.4 Application Server mode The Broadcast mode shall not be used. ETSI 7 ETSI TS 102 141 V1.l.l (2003-05) 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 acti

30、ve, and shall remain active until the last ASP becomes inactive. 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 butio

31、n to the Application Server The key to enable messages to be distributed to the appropriate AS shall have a granularity no smaller than is allowed by the management messages appropriate to that layer. 4.8 Receipt of unrecognized messages If a message with an unrecognized message class is received, a

32、 Management Error message shall be returned with Error Code “Unsupported Message Class“. 5 Considerations applicable to M2UA 5.1 M2UA procedures The M2UA procedures shall be as defined in RFC 333 1 2 augmented by ITU-T Recommendations Q.701 3, Q.702 4 and Q.703 5 as modified by EN 300 008-1 i, excep

33、t where otherwise defined below. 5.2 National options No national options excluded by EN 300 008-1 i shall apply to the present document. 5.3 Dynamic reg ist ra ti on Dynamic registration of Link Keys shall not be used for configuration management. The configuration of the system shall be modified o

34、nly by the management system, and not by the protocol itself. 5.4 Message distri bution to the Application Server No special considerations for message distribution to the Application Server apply for M2UA. 5.5 Using of the terms MGC (Media Gateway Controller) and ASP (Application Server process) Th

35、e terms “MGC“ and “ASP“ have the same meaning in the present document. ETSI 8 ETSI TS 102 141 V1.l.l (2003-05) 6 Modifications to RFC 3331 Modifications to RFC 333 1 2 are listed according to the sections and subsections of RFC 333 1 2. Section 1 Introduction ANSI references do not apply. Add a refe

36、rence EN 300 008-1 i. Subsection 1.3 M2UA Overview ANSI references do not apply. Add a reference EN 300 008-1 i. Subsection 1.3.1 Example - SG to MGC SCTP shall be used as the transport protocol for M2UA. TCP shall not be used as the transport protocol for M2UA. Subsection 1.3.3 ClientBerver Model T

37、he SGP shall be able to support SCTP server operation and the ASP shall be able to support SCTP client operation. Support of both SCTP client and SCTP server operation at the ASP or SGP is optional. Subsection 1.4.2 Support for communication between Layer Management modules on SG and MGC NOTE: M-ERR

38、OR is a primitive, not a message. Subsection 1.4.3 Support for management of active associations between SG and MGC The M2UA layer shall inforin its local Layer Management of the status of its underlying SCTP associations. This is done by use of the M-SCTP-STATUS primitive. The Layer Management shal

39、l inform the M2UA layer of an AS/ASP status (i.e. failure, active, etc.) so that messages can be exchanged to stop traffic to the local M2UA user. Subsection 1.5.2 Support for the management of SCTP associations between the SGPs and ASPS If instructed by the local management, the M2UA layer shall in

40、itiate the establishment of a SCTP association to a peer M2UA node. The M2UA layer shall also inform the local management of the status of underlying SCTP associations using the M-SCTP-STATUS request and the indication primitive. Also the M2UA layer shall inform the local management of the change in

41、 status of an ASP or AS. Subsection 1.5.3 Status of ASPS The M2UA layer shall inform the local management of the change in status of ASP or AS. Subsection 1.5.5 Seamless SS7 Network Management Interworking The M2UA on the SGP shall pass an indication of unavailability of the M2UA-User (MTP3) to the

42、Local Management, if the currently active ASP moves from the ACTIVE state. The actions taken by M2UA on the SGP with regards to MTP Level 2 shall be in accordance with EN 300 008-1 i. Subsection 1.5.6 Flow Control / Congestion When M2UA is informed of IP congestion onset or congestion abatement by t

43、he SCTP, the actions taken by the SG shall be in accordance with EN 300 008-1 i. Subsection 1.6.4 Definition of Layer Management / M2UA Boundary M-SCTP-RELEASE indication primitive shall also be used by the SGP to inform Layer Management that the SCTP association has failed. ETSI 9 ETSI TS 102 141 V

44、1.l.l (2003-05) The M-SCTP-STATUS confirmation primitive shall be added: Direction: M2UA 4 LM Purpose: M2UA responds with the status of a SCTP association. The M-ASP-STATUS confirmation primitive shall be used instead of M-ASP-STATUS indication: Direction: M2UA 4 LM Purpose: M2UA reports the status

45、of a local or remote ASP. The M-AS-STATUS confirmation primitive shall be used instead of M-AS-STATUS indication: Direction: M2UA 4 LM Purpose: SG reports the status of an AS. M-LINK-KEY-REG primitives and M-LINK-KEY-DEREG primitives shall not be used. The following primitives shall be added: M-ASP-

46、UP indication Direction: M2UA 4 LM Purpose: M2UA reports it has successfully processed an incoming ASP Up message from its peer. M-ASP-DOWN indication Direction: M2UA 4 LM Purpose: M2UA reports it has successfully processed an incoming ASP Down message from its peer, or the SCTP association has been

47、 lost/restart. M-ASPACTIVE indication Direction: M2UA 4 LM Purpose: M2UA reports it has successfully processed an incoming ASP Active message from its peer. M-ASP-INACTIVE indication Direction: M2UA 4 LM Purpose: M2UA reports it has successfully processed an incoming ASP Inactive message from its pe

48、er. M-AS-ACTIVE indication Direction: M2UA 4 LM Purpose: M2UA reports that an AS has moved to the AS-ACTIVE state. M-AS-INACTIVE indication Direction: M2UA 4 LM Purpose: M2UA reports that an AS has moved to the AS-INACTIVE state. M-AS-DOWN indication Direction: M2UA 4 LM Purpose: M2UA reports that a

49、n AS has moved to the AS-DOWN state. ETSI 10 ETSI TS 102 141 V1.l.l (2003-05) M-ERROR-OCC indication Direction: M2UA 4 LM Purpose: M2UA reports an error condition to LM. Subsection 3.1.3 Message Class MGMT messages shall use SCTP stream O, ASPSM messages shall use stream O (apart from BEAT and BEAT ACK which can use any stream), ASPTM messages shall use a traffic stream, MAUP messages shall use any but stream O. Interface Identifier Management (IIM) messages shall not be used. If an Interface Identifier Management (IIM) message i