Recommendation Q.712
DEFINITION AND FUNCTION OF SCCP MESSAGES
1	Signalling connection control part messages
	The signalling connection control part (SCCP) messages are used by the peer–to–peer 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.
	It is used during connection establishment phase by connection–oriented protocol class 2 or 3.
1.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.
	It is used during connection establishment phase by connection–oriented protocol class 2 or 3.
1.3	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.
	It is used during connection establishment phase by connection–oriented protocol class 2 or 3.
1.4	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.

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 (re–initialization of sequence numbers) with the receiving SCCP.
	It is used during the data transfer phase in protocol class 3.
1.15	Subsystem–Allowed (SSA)
	A Subsystem–Allowed 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.

1.16	Subsystem–Out–of–Service–Grant (SOG)
	A Subsystem–Out–of–Service–Grant message is sent, in response to a Subsystem–Out–of–Service–Request 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	Subsystem–Out–of–Service–Request (SOR)
	A Subsystem–Out–of–Service message is used to allow subsystems to go out–of–service without degrading performance of the network. When a subsystem wishes to go out–of–service, the request is transferred by means of a Subsystem–Out–of–Service–Request 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	Subsystem–Prohibited (SSP)
	A Subsystem–Prohibited 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	Subsystem–Status–Test (SST)
	A Subsystem–Status–Test 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	SCCP parameter
2.1	affected point code
	The “affected point code” identifies a signalling point where the affected subsystem is located.
2.2	affected subsystem number
	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.

	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 connection–oriented or connectionless message.
	For a connection–oriented 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 connection–oriented 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 connection–oriented 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 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.

2.11	receive sequence number
	The “receive sequence number” parameter field P(R) is used in the data 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 (M–bit). This is used only in connection–oriented 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	mandatory field
	o	optional field (which is included in a message when needed)

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

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