_______________

Recommendation Q.712
DEFINITION AND FUNCTION OF SCCP MESSAGES

Signalling connection control part messages

The signalling connection control part (SCCP) messages are used by the peertopeer protocol. All messages are uniquely identified by means of a message type code, which is to be found in all the messages. The meaning and definition of the various parameter fields contained in these messages are specified in 2. The actual inclusion of these parameter fields in a given message depends on the class of protocol and is specified in 3. 1.1 Connection Confirm (CC)

A Connection Confirm message is sent by the called SCCP to indicate to the calling SCCP that it has performed the setup of the signalling connection. On reception of a Connection Confirm message, the calling SCCP completes the setup of the signalling connection, if possible. or 3. 1.2 It is used during connection establishment phase by connectionoriented protocol class 2

Connection Request (CR)

A Connection Request message is sent by a calling SCCP to a called SCCP to request the setting up of a signalling connection between the two entities. The required characteristics of the signalling connection are carried in various parameter fields. On reception of a Connection Request message, the called SCCP initiates the setup of the signalling connection if possible. or 3. 1.3 It is used during connection establishment phase by connectionoriented protocol class 2

Connection Refused (CREF)

A Connection Refused message is sent by the called SCCP or an intermediate node SCCP to indicate to the calling SCCP that the setup of the signalling connection has been refused. or 3. 1.4 It is used during connection establishment phase by connectionoriented protocol class 2

Data Acknowledgement (AK)

A Data Acknowledgement message is used to control the window flow control mechanism, which has been selected for the data transfer phase. It is used during the data transfer phase in protocol class 3. 1.5 Data Form 1 (DT1)

A Data Form 1 message is sent by either end of a signalling connection to pass transparently SCCP user data between two SCCP nodes. It is used during the data transfer phase in protocol class 2 only. 1.6 Data Form 2 (DT2)

A Data Form 2 message is sent by either end of a signalling connection to pass transparently SCCP user data between two SCCP nodes and to acknowledge messages flowing in the other direction. It is used during the data transfer phase in protocol class 3 only. Fascicle VI.7 Rec. Q.712 1

1.7

Expedited Data (ED)

An Expedited Data message functions as a Data Form 2 message but includes the ability to bypass the flow control mechanism which has been selected for the data transfer phase. It may be sent by either end of the signalling connection. It is used during the data transfer phase in protocol class 3 only. 1.8 Expedited Data Acknowledgement (EA)

An Expedited Data Acknowledgement message is used to acknowledge an Expedited Data message. Every ED message has to be acknowledged by an EA message before another ED message may be sent. It is used during the data transfer phase in protocol class 3 only. 1.9 Inactivity Test (IT)

An Inactivity Test message may be sent periodically by either end of a signalling connection to check if this signalling connection is active at both ends, and to audit the consistency of connection data at both ends. It is used in protocol classes 2 and 3. 1.10 Protocol Data Unit Error (ERR) A Protocol Data Unit Error message is sent on detection of any protocol errors. It is used during the data transfer phase in protocol classes 2 and 3. 1.11 Released (RLSD)

A Released message is sent, in the forward or backward direction, to indicate that the sending SCCP wants to release a signalling connection and the associated resources at the sending SCCP have been brought into the disconnect pending condition. It also indicates that the receiving node should release the connection and any other associated resources as well. It is used during connection release phase in protocol classes 2 and 3. 1.12 Release Complete (RLC)

A Release Complete message is sent in response to the Released message indicating that the Released message has been received, and the appropriate procedures has been completed. It is used during connection release phase in protocol classes 2 and 3. 1.13 Reset Confirm (RSC)

A Reset Confirm message is sent in response to a Reset Request message to indicate that Reset Request has been received and the appropriate procedure has been completed. It is used during the data transfer phase in protocol class 3. 1.14 Reset Request (RSR)

A Reset Request message is sent to indicate that the sending SCCP wants to initiate a reset procedure (reinitialization of sequence numbers) with the receiving SCCP. It is used during the data transfer phase in protocol class 3. 1.15 SubsystemAllowed (SSA)

A SubsystemAllowed message is sent to concerned destinations to inform those destinations that a subsystem which was formerly prohibited is now allowed. It is used for SCCP subsystem management. 2 Fascicle VI.7 Rec. Q.712

1.16

SubsystemOutofServiceGrant (SOG)

A SubsystemOutofServiceGrant message is sent, in response to a SubsystemOutof ServiceRequest message, to the requesting SCCP if both the requested SCCP and the backup of the affected subsystem agree to the request. It is used for SCCP subsystem management. 1.17 SubsystemOutofServiceRequest (SOR)

A SubsystemOutofService message is used to allow subsystems to go outofservice without degrading performance of the network. When a subsystem wishes to go outofservice, the request is transferred by means of a SubsystemOutofServiceRequest message between the SCCP at the subsystem's node and the SCCP at the duplicate subsystem's node. It is used for SCCP subsystem management. 1.18 SubsystemProhibited (SSP)

A SubsystemProhibited message is sent to concerned destinations to inform SCCP Management (SCMG) at those destinations of the failure of a subsystem. It is used for SCCP subsystem management. 1.19 SubsystemStatusTest (SST)

A SubsystemStatusTest message is sent to verify the status of a subsystem marked prohibited. It is used for SCCP subsystem management. 1.20 Unitdata (UDT) A Unitdata message is used by a SCCP wanting to send data in a connectionless mode. It is used in connectionless protocol classes 0 and 1. 1.21 Unitdata Service (UDTS)

A Unitdata Service message is used to indicate to the originating SCCP that a UDT it sent cannot be delivered to its destination. A UDTS message is sent only when the option field in that UDT is set to return on error. It is used in connectionless protocol classes 0 and 1. 2 2.1 located. 2.2 affected subsystem number SCCP parameter affected point code The affected point code identifies a signalling point where the affected subsystem is

The affected subystem number parameter field identifies a subsystem which is failed, withdrawn, congested or allowed. In the case of SST messages, it also identifies the subsystem being audited. In the case of SOR or SOG messages, it identifies a subsystem requesting to go out of service. 2.3 calling/called party address

The calling/called party address parameter field contains enough information to uniquely identify the origination/destination signalling point and/or the SCCP service access point.

Fascicle VI.7 Rec. Q.712

It can be any combination of a global title (dialled digits for example), a signalling point code, and a subsystem number. The subsystem number (SSN) identifies a SCCP user function when provided. In order to allow the interpretation of this address, it begins with an address indicator indicating which information elements are present. The address indicator also includes a routing indicator specifying if translation is required, and a global title indicator specifying global title format. The calling/called party address parameter field has two different meanings depending on whether it is included in a connectionoriented or connectionless message. For a connectionoriented message, the significance of these fields is related to the direction of the connection setup (i.e. independent of the direction the message is going. For a connectionless message, the significance of these fields is dependent on the direction the message is going (just as for OPC and DPC). 2.4 credit

The credit parameter field is used in the acknowledgements to indicate to the sender how many messages it may send, i.e., window size. It is also used in the CR and CC message to indicate the proposed and selected credit, and in the IT message to audit the consistency of this connection data at both ends of a connection section. 2.5 data

The data parameter field contains information coming from upper layers or from SCCP management. In connectionless and connectionoriented messages the data parameter field contains information coming from the upper layers. Information coming from SCCP management will be contained in the data parameter field of a UDT message. In this case the data parameter field of the UDP message will only contain the SCCP management message. 2.6 diagnostic The diagnostic parameter field is for further study. 2.7 error cause

The error cause parameter field is used in the Protocol Data Unit Error message in order to indicate what is the exact protocol error. 2.8 end of optional parameters

The end of optional parameters parameter field is used in any message containing optional parameters to indicate where the part allocated to these optional parameters ends. 2.9 local reference number (source/destination)

The local reference number (source/destination) parameter field uniquely identifies in a node a signalling connection. It is an internal working number chosen by each node independently from the destination node. At least one local reference number is to be found in any message exchanged on a signalling connection section. Note Remote reference number is used to reflect the local reference number at the remote end of a connection section. 2.10 protocol class

For connectionoriented protocol classes, the protocol class parameter field is used during the connection establishment phase; it is negotiated between the two end SCCP. It is also

Fascicle VI.7 Rec. Q.712

used during data transfer phase to audit the consistency of this connection data at both ends of a connection section. For connectionless protocol classes the protocol class parameter field is used to indicate whether or not a message should be returned on error occurence.

Fascicle VI.7 Rec. Q.712

2.11

receive sequence number in the data

The receive sequence number parameter field P(R) is used acknowledgement message to indicate the lower edge of the receiving window.

It also indicates that at least all messages numbered up to and including P(R) 1 are accepted. 2.12 refusal cause

The refusal cause parameter field is used in a Connection Refused message to indicate the reason why the connection setup request was refused. 2.13 release cause

The release cause parameter field is used in a Released message to indicate the reason of the release. 2.14 reset cause

The reset cause parameter field is used in a Reset Request message to indicate the reason why a reset procedure is invoked. 2.15 return cause

For connectionless protocol classes, the return cause parameter field is used to indicate the reason why a message was returned. 2.16 segmenting/reassembling

The segmenting/reassembling parameter field is used in the data message for the segmenting and reassembling function. It is the more data indicator (Mbit). This is used only in connectionoriented messages. It is set to one in a data message to indicate that more data will follow in a subsequent message. It is set to zero in a data message to indicate that the data in this message forms the end of a complete data sequence. 2.17 sequencing/segmenting

The sequencing/segmenting parameter field contains the information necessary for the following functions: sequence numbering, flow control, segmenting and reassembling. 2.18 subsystem multiplicity indicator

The subsystem multiplicity indicator is used in SCCP management messages to indicate the number of associated replicated subsystems. 3 Inclusion of fields in the messages

The inclusion of the information elements specified in 2 in the various messages specified in 1 according to their type depends on the class of protocol. SCCP messages are specified in Table 1/Q.712 and SCCP management messages are specified in Table 2/Q.712. All SCCP management messages are embedded in the data parameter of the Unitdata message. The following applies to Tables 1/Q.712 and 2/Q.712: m o mandatory field optional field (which is included in a message when needed)

Fascicle VI.7 Rec. Q.712

Table 1/Q.712 - Landscape. File: 712T1E.DOC

Fascicle VI.7 Rec. Q.712

TABLE 2/Q.712 SCCP management messages Messages SSA Parameter fields SCMG format ID Affected SSN Affected PC Subsystem multiplicity indicator m m m m m m m m m m m m m m m m m m m m SSP SST SOR SOG

Fascicle VI.7 Rec. Q.712