ETSI TS 102 143 V1.1.1 (2003-05)

SLOVENSKI STANDARD
SIST-TS ETSI/TS 102 143 V1.1.1:2005
01-januar-2005
Storitve in protokoli za napredna omrežja (SPAN) – MTP/SCCP/SSCOP in SIGTRAN
(prenos SS7 preko IP) – Uporabniška prilagodilna plast (SUA) krmilnega dela
signalizacijske zveze [privzeti SIGTRAN–SUA–14 (december 2002), spremenjen]
Services and Protocols for Advanced Networks (SPAN); MTP/SCCP/SSCOP and

SIGTRAN (Transport of SS7 over IP); Signalling connection control part User Adaptation

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

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 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

Users of the present document should be aware that the document may be subject to revision or change of status.

Information on the current status of this and other ETSI documents is available at

DECT , PLUGTESTS and UMTS are Trade Marks of ETSI registered for the benefit of its Members.

TIPHON and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members.

3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.

Intellectual Property Rights................................................................................................................................4

Foreword.............................................................................................................................................................4

Endorsement notice ............................................................................................................................................4

Introduction ........................................................................................................................................................4

1 Scope........................................................................................................................................................5

2 References................................................................................................................................................5

3 Abbreviations...........................................................................................................................................6

4 General considerations applicable to transport of Signalling System No. 7 over IP................................6

4.1 Transport protocol..............................................................................................................................................7

4.2 SCTP considerations..........................................................................................................................................7

4.3 National options.................................................................................................................................................7

4.4 Application Server mode....................................................................................................................................7

4.5 Application Server state handling.......................................................................................................................7

4.6 Dynamic registration..........................................................................................................................................7

4.7 Message distribution to the Application Server..................................................................................................7

4.8 Receipt of unrecognized messages.....................................................................................................................7

5 General considerations applicable to SUA...............................................................................................7

5.1 National options.................................................................................................................................................7

5.2 Dynamic registration..........................................................................................................................................8

5.3 Message distribution to the Application Server..................................................................................................8

5.4 SUA procedures.................................................................................................................................................8

5.5 Class 3 operation ................................................................................................................................................8

5.6 N-PCSTATE primitive.......................................................................................................................................8

6 Modifications to SUA-14 .........................................................................................................................8

Annex A (informative): Bibliography...................................................................................................22

History ..............................................................................................................................................................23

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); Essential, 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

All published ETSI deliverables shall include information which directs the reader to the above source of information.

This Technical Specification (TS) has been produced by ETSI Technical Committee Services and Protocols for

The elements of Internet Engineering Task Force Internet Draft draft-ietf-sigtran-sua-14 [3], apply with the following

The present document records the changes to the Internet Engineering Task Force (IETF) draft SUA document. IETF

drafts are transient documents, eventually the SUA draft is expected to be replaced with an RFC, which will persist on

the IETF website. However, ETSI will keep a copy of the IETF draft on its website until the present document is

The present document is applicable to the international network and does not intend to restrict national networks.

However to facilitate interworking, its adoption within national networks is preferred.

The present document specifies the Signalling Connection Control Part (SCCP) User Adaptation layer signalling

protocol for connecting SCCP Users via Signalling System No. 7 SCCP international relay points and signalling

The present document endorses and constrains where relevant the SIGTRAN SUA of [3].

The following documents contain provisions which, through reference in this text, constitute provisions of the present

• References are either specific (identified by date of publication and/or edition number or version number) or

Referenced documents which are not found to be publicly available in the expected location might be found at

[1] ETSI EN 300 009-1: "Signalling Connection Control part (SCCP) (connectionless and connection-

[2] ETSI EN 300 008-1: "Integrated Services Digital Network (ISDN); Signalling System No.7;

Message Transfer Part (MTP) to support international interconnection; Part 1: Protocol

specification [ITU-T Recommendations Q.701, Q.702, Q.703, Q.704, Q.705, Q.706, Q.707 and

[3] IETF Internet Draft draft-ietf-sigtran-sua-14: "Signalling Connection Control Part User Adaptation

[4] ITU-T Recommendation Q.714: "Specifications of Signalling System No. 7, Signalling connection

[5] ETSI EG 201 693: "Integrated Services Digital Network (ISDN); Signalling System No.7; Master

[6] ITU-T Recommendation Q.704: "Specifications of Signalling System No. 7, Message Transfer

[7] ITU-T Recommendation Q.711: "Signalling System No.7 - Functional Description of the

[8] ITU-T Recommendation Q.713: "Signalling connection control part formats and codes".

[10] ETSI TS 102 144: "Services and Protocols for Advanced Networks (SPAN); MTP/SCCP/SSCOP

[11] 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)

[12] 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)

[13] IETF RFC 3332 (2002): "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User

The elements of SIGTRAN adaptation layers apply with the following exceptions and restrictions. The considerations

in this clause are common to TS 102 141 [11], TS 102 142 [12] and the present document.

The protocol underlying the adaptation layer for transport of SS No.7 signalling information in IP networks shall be

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 neither the IANA payload protocol identifier nor payload

No national options excluded by ETSI standards shall apply to the present document.

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.

Dynamic registration shall not be used for configuration management. The configuration of the system shall be

The key to enable messages to be distributed to the appropriate AS shall have a granularity no smaller than is allowed

If a message with an unrecognized message class is received, a Management Error message shall be returned with Error

No national options excluded by EN 300 009-1 [1] and EN 300 008-1 [2] shall apply to the present document.

Dynamic registration of Routing Keys shall not be used for configuration management. The configuration of the system

The Routing Key to enable messages to be distributed to the appropriate AS shall have a granularity no smaller than

The SUA procedures shall be as defined in [3] augmented by ITU-T Recommendation Q.714 [4] as modified by

The N-PCSTATE primitive's signalling point status parameter (see ITU-T Recommendation Q.711 [7] clause 6.3.2.2.5)

has in [3] been extended to convey information about the restricted status of the signalling point. However, this shall not

Routing Key: Dynamic registration of Routing Keys 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.

Add the definition of Network Appearance taken from RFC 3332 [13] (which has been extended for SUA) viz:

• "Network Appearance - The Network Appearance is an SUA local reference (typically an integer) shared by

SG and AS that together with a Signalling Point Code or global title uniquely identifies an SS7 node by

NOTE: The entity labelled "SEP or STP" is just an SEP here since it contains an SCCP User.

NOTE: The SG can act as an endpoint with messages routed to it also by global title, if the global title translation

NOTE: Global Title Translation yields an "entity set", not an "entity". A way of viewing the AS is then as an

"entity set", with each ASP that the AS uses viewed as an "entity" within the set.

"In this architecture, the SCCP and SUA layers in the SGP interface to support connection-oriented data transfer

between SEP and ASP. Connection sections are setup when routing the Connect Request messages from SEP via SGP

NOTE: The entity labelled "SEP or STP" is just an SEP here since it contains an SCCP User.

• N-STATE is defined in ITU-T Recommendation Q.711 [7], clause 6.3.2.3.2, table 16/Q.711.

• N-PCSTATE is defined in ITU-T Recommendation Q.711 [7], clause 6.3.2.3.3, table 17/Q.711.

• N-COORD is defined in ITU-T Recommendation Q.711 [7], clause 6.3.2.3.1, table 15/Q.711.

The SUA shall also provide interworking with SCCP management functions at the SG to inform concerned SCCP users

in the SS No.7 network about the availability, accessibility and congestion status of SUA/SUA users in the managed IP

If messages are discarded when there is no address match, a report shall be made to Layer Management.

It is preferable to route messages to the SG on Global Title within the SS No.7 network, rather than on SSN (+ PC), if

the relay function is to be invoked at the SG (with the SG's incoming SCCP itself performing a Global Title

Translation). This helps the SG to avoid performing multi-point code working at its MTP level.

If the relay function is to be invoked for messages from the IP network directly to the SS No.7 network, resolution of

the address information shall yield the information required in ITU-T Recommendation Q.714 [4], clause 2.2.2.

A set of signalling messages requiring to be delivered in the same sequence as they are sent shall use the same SCTP

How local and IP network congestion is reported to SUA is nodal implementation-dependent. But SUA shall be told if

When an SG determines that the transport of SS7 messages is encountering congestion, the SG shall trigger SS7 SCCP

Congestion messages to originating SS7 nodes according to the congestion procedures of ITU-T

The triggering of SS No.7 SCCP Management messages from an SG shall be done if congestion occurs. The means of

When an SG receives a congestion message (SCON) from an ASP, and the SG determines that an endpoint.

is now encountering congestion, it shall trigger congestion procedures as per ITU-T Recommendation Q.714 [4].

The receiving node shall be able to detect local congestion and inform the transmitting node of this, by whatever means.

Class 3 operation is not in the scope of the present document. If a connection request asks for class 3, and the node

• N-EXPEDITED DATA and N-RESET pertain to class 3 operation, and are not in the scope of the present

• N-INFORM is defined in ITU-T Recommendation Q.711 [7], clause 6.1.1.3.2, table 8/Q.711.

• N-UNIT DATA is defined in ITU-T Recommendation Q.711 [7], clause 6.2.2.3.1, table 12/Q.711.

• N-NOTICE is defined in ITU-T Recommendation Q.711 [7], clause 6.2.2.3.2, table 13/Q.711.

• Add N-COORD, N-STATE and N-PCSTATE primitives, defined in ITU-T Recommendation Q.711 [7],

Add the primitive M-ERROR_occ indication, in the direction SUA to LM, with purpose SUA reports an error condition

• "The Reserved field shall be set to 0 in messages sent, and shall not be examined on reception".

MGMT messages shall use SCTP stream 0, SNM messages shall use stream 0, ASPSM messages shall use stream 0

(apart from BEAT ACK which can use any stream), ASPTM messages shall use a traffic stream, CL and CO messages

NOTE: Stream 0 shall be used for SNM messsages, since DUNA, DAVA, DUPU messages referring-to the same

destination must be delivered in the order in which they are sent, and DUNA and DAVA messages

without SSN parameters can contain a list of destinations in their Affected Point Code parameter. The list

in a DUNA or DAVA might contain some the same, and some different, destinations as a following

The default Importance value for MGMT messages shall be 8 for NTFY and 7 for ERR.

The default Importance value for SNM messages shall be 6 for DUNA, DAVA, DUPU, DAUD and SCON, it shall be 5

The default Importance value for ASPSM messages shall be 8 for all except BEAT ACK, which shall be 2.

The default Importance values for CL and CO messages shall be the same as those defined in ITU-T Recommendation

Q.714 [4] table 2/Q.714 for the equivalent messages. The maximum Importance values for CL and CO messages shall

be the same as those defined in ITU-T Recommendation Q.714 [4] table 2/Q.714 for the equivalent messages.

If a Routing Key Management message is received an Error (ERR) message shall be returned with Error Code

"Unsupported Message Class", the RKM message shall be discarded and a report made to Layer Management.

Destination Restricted (DRST) shall only be used when equivalent to an SCCP N-COORD primitive, but this is

required only for separate nodes containing replicated subsystems, where these nodes also support SCCP management

DRST equivalent to the SCCP N-PCSTATE indication primitive with Signalling point status parameter set to

"destination restricted" shall not be sent. If such a N-PCSTATE primitive is received in the SUA, it shall be discarded

Heartbeat is not required and BEAT shall not be sent. If a BEAT is received, a BEAT ACK shall be sent in response. If

a BEAT ACK is received, it shall be discarded and a report made to Layer Management.

These messages shall not be sent. If a Routing Key Management message is received an Error (ERR) message shall be

returned with Error Code "Unsupported Message Class", the RKM message shall be discarded and a report made to

Reset Confirm, Reset Request and Connection Oriented Data Acknowledge messages are not in the scope of the present

For protocol class 0 messages, the sending SUA layer shall take into account the loading of SCTP streams when setting

Note that if a Segmentation parameter is present and its first/remaining segments field indicates more than one segment,

the value of the Sequence Control parameter shall be the same (non-zero) value for all segments of the group (i.e. all

segments with the same Segmentation Reference value, Source and Destination Addresses).

The CLDR message shall be used if a message is returned from the node itself (conveyed in an N-NOTICE indication

to SUA), in addition to its use when a node receives an (X)(L)UDTS message for onward transfer.

DT2 and ED shall not be sent. If received they shall be discarded and a report made to Layer Management.

If a CORE message is received with Protocol Class indicating class 3, and the node supports SCCP management

procedures and class 2 but not class 3, the class shall be lowered to 2 in the COAK message sent in reply (see

EN 300 009-1 [1], page 12 "Page 25, clause 3.1.3.1" and "Page 27, clause 3.1.5.1").

For actions on reception of a COAK message for protocol class other than 2, see EN 300 009-1 [1], page 12 "Page 26,

A DUNA message containing an SSN shall contain in the Affected Point Code parameter just one point code, that of the

For DUNA messages not containing an SSN, it is optional to send an Affected Point Code parameter with more than

one point code in it, but the ability to receive such a parameter is mandatory. The SG may limit the frequency at which

it sends by the response method DUNAs referring to a particular destination, to 1 in the T8 interval of ITU-T

A DAVA message containing an SSN shall contain in the Affected Point Code parameter just one point code, that of the

For DAVA messages not containing an SSN, it is optional to send an Affected Point Code para