Recommendation Q.713
SCCP FORMATS AND CODES
1	General
	The Signalling Connection Control Part (SCCP) messages are carried on the signalling data link by means of Signal Units the format of which is described in Recommendation Q.703, § 2.2.
	The Service Information Octet format and coding is described in Recommendation Q.704, § 14.2. The Service Indicator is coded 0011 for the SCCP.
	The Signalling Information Field (SIF) of each Message Signal Unit containing an SCCP message consists of an integral number of octets.
	A message consists of the following parts (see Figure 1/Q.713):
–	the routing label;
–	the message type code;
–	the mandatory fixed part;
–	the mandatory variable part;
–	the optional part, which may contain fixed length and variable length fields.
	The description of the various parts is contained in the following sections. SCCP Management messages and codes are provided in § 5 of this Recommendation.
1.1	Routing label
	The standard routing label specified in Recommendation Q.704, § 2.2 is used. The rules for the generation of the signalling link selection (SLS) code are described in Recommendation Q.711, § 2.2.1.

Routing label	
Message type code	
Mandatory fixed part	
Mandatory variable part	
Optional part	
FIGURE 1/Q.713
General layout

1.2	Message type code
	The message type code consists of a one octet field, and is mandatory for all messages. The message type code uniquely defines the function and format of each SCCP message. The allocation of message type codes, with reference to the appropriate descriptive section of this Recommendation is summarized in Table 1/Q.713. Table 1/Q.713 also contains an indication of the applicability of the various message types to the relevant classes of protocol.
1.3	Formatting principles
	Each message consists of a number of parameters listed and described in § 3. Each parameter has a “name” which is coded as a single octet (see § 3). The length of a parameter may be fixed or variable, and a “length indicator” of one octet for each parameter may be included as described below.
	The detailed format is uniquely defined for each message type as described in § 4.
	A general SCCP message format is shown in Figure 2/Q.713.
1.4	Mandatory fixed part
	Those parameters that are mandatory and of fixed length for a particular message type will be contained in the “mandatory fixed part”. The position, length and order of the parameters is uniquely defined by the message type. Thus the names of the parameters and the length indicators are not included in the message.
1.5	Mandatory variable part
	Mandatory parameters of variable length will be included in the mandatory variable part. The name of each parameter and the order in which the pointers are sent is implicit in the message type. Parameter names are, therefore, not included in the message. A pointer is used to indicate the beginning of each parameter. Because of this, parameters may be sent in an order different from that of the pointers. Each pointer is encoded as a single octet. The details of how pointers are encoded is found in § 2.3. The number of parameters, and thus the number of pointers is uniquely defined by the message type.
	A pointer is also included to indicate the beginning of the optional part. If the message type indicates that no optional part is allowed, then this pointer will not be present. If the message type indicates that an optional part is possible, but there is no optional part included in this particular message, then a pointer field containing all zeros will be used.
	All the pointers are sent consecutively at the beginning of the mandatory variable part. Each parameter contains the parameter length indicator followed by the contents of the parameter.
Figure 2/Q.713 - CCITT 73070

1.6	Optional part
	The optional part consists of parameters that may or may not occur in any particular message type. Both fixed length and variable length parameters may be included. Optional parameters may be transmitted in any order1). Each optional parameter will include the parameter name (one octet) and the length indicator (one octet) followed by the parameter contents.
1.7	End of optional parameters octet
	After all optional parameters have been sent, an end of optional parameters octet containing all zeroes will be transmitted. This octet is only included if optional parameters are present in the message.
1.8	Order of transmission
	Since all the parameters consist of an integral number of octets, the formats are presented as a stack of octets. The first octet transmitted is the one shown at the top of the stack and the last is the one at the bottom (see Figure 2/Q.713).
	Within each octet, the bits are transmitted with the least significant bit first.
1.9	Coding of spare bits
	According to the general rules defined in Rec. Q.700, spare bits are coded 0 unless indicated otherwise at the originating nodes. At intermediate nodes, they are passed transparently. At destination nodes, they need not be examined.
1.10	National message types and parameters
	If message type codes and parameter codes are required for national uses, it is suggested that the codes be selected from the highest code downwards, that is starting at code 11111110. Code 11111111 is reserved for future use.
2	Coding of the general parts
2.1	Coding of the message type
	The coding of the message is shown in Table 1/Q.713.
2.2	Coding of the length indicator
	The length indicator field is binary coded to indicate the number of octets in the parameter content field. The length indicator does not include the parameter name octet or the length indicator octet.
2.3	Coding of the pointers
	The pointer value (in binary) gives the number of octets between the pointer itself (included) and the first octet (not included) of the parameter associated with that pointer2).
	The pointer value all zeros is used to indicate that, in the case of optional parameters, no optional parameter is present.
3	SCCP parameters
	The parameter name codes are given in Table 2/Q.713 with reference to the subsections in which they are described.
3.1	End of optional parameters
	The “end of optional parameters” parameter field consists of a single octet containing all zeros.
3.2	Destination local reference
	The “destination local reference” parameter field is a three–octet field containing a reference number which, in outgoing messages, has been allocated to the connection section by the remote node.
	The coding “all ones” is reserved, its use is for further study.
TABLE 1/Q.713
SCCP message types
	Classes						
Message type	0	1	2	3	§	Code	
CR Connection Request			X	X	4.2	0000 0001	
CC Connection Confirm			X	X	4.3	0000 0010	
CREF Connection Refused			X	X	4.4	0000 0011	
RLSD Released			X	X	4.5	0000 0100	
RLC Release Complete			X	X	4.6	0000 0101	
DT1 Data Form 1			X		4.7	0000 0110	
DT2 Data Form 2				X	4.8	0000 0111	
AK Data Acknowledgement				X	4.9 	0000 1000	
UDT Unitdata	X	 X			4.10	0000 1001	
UDTS Unitdata Service	X	X			4.11	0000 1010	
ED Expedited Data				X	4.12	0000 1011	
EA Expedited Data Acknowledgement				X	4.13	0000 1100	
RSR Reset Request				X	 4.14	0000 1101	
RSC Reset Confirm				X	 4.15	0000 1110	
ERR Protocol Data Unit Error			X	 X	 4.16	 0000 1111	
IT Inactivity Test			X	X	4.17	 0001 0000	
X	Type of message in this protocol class.

TABLE 2/Q.713
SCCP parameter name codes
Parameter name	§	Parameter name code 8765 4321	
End of optional parameters	3.1	0000 0000	
Destination local reference	3.2	0000 0001	
Source local reference	3.3	0000 0010	
Called party address	3.4	0000 0011	
Calling party address	3.5	0000 0100	
Protocol class	3.6	0000 0101	
Segmenting/reassembling	3.7	0000 0110	
Receive sequence number	3.8	0000 0111	
Sequencing/segmenting	3.9	0000 1000	
Credit	3.10	0000 1001	
Release cause	3.11	0000 1010	
Return cause	3.12	0000 1011	
Reset cause	3.13	0000 1100	
Error cause	3.14	0000 1101	
Refusal cause	3.15	0000 1110	
Data	3.16	0000 1111	

3.3	Source local reference
	The “source local reference” parameter field is a three–octet field containing a reference number which is generated and used by the local node to identify the connection section.
	The coding “all ones” is reserved, its use is for further study.
3.4	Called party address
	The “called party address” is a variable length parameter. Its structure is shown in Figure 3/Q.713.

	8	7	6	5	4	3	2	1	
Octet 1	Address indicator								
Octet 2									
.									
.	Address								
.									
Octet n									
FIGURE 3/Q.713 
Called/Calling party address
3.4.1	Address indicator
	The “address indicator” indicates the type of address information contained in the address field (see Figure 4/Q.713). The address consists of one or any combination of the following elements:
–	signalling point code;
–	global title (for instance, dialled digits);
–	subsystem number.

8	7	6	5	4	3	2	1	
Reserved for national use	Rtg indicator	Global title indicator				SSN indicator	Point code indicator	
FIGURE 4/Q.713
Address indicator encoding

	A “1” in bit 1 indicates that the address contains a signalling point code.
	A “1” in bit 2 indicates that the address contains a subsystem number.
	Bits 3–6 of the address indicator octet contain the global title indicator, which is encoded as follows:

Bits	6 5 4 3		
	0 0 0 0		No global title included	
	0 0 0 1		Global title includes nature of address indicator only	
	0 0 1 0		Global title includes translation type only3)	
	0 0 1 1		Global title includes translation type, numbering plan and encoding scheme3)	
	0 1 0 0		Global title includes translation type, numbering plan, encoding scheme and nature of address indicator	
	0 1 0 1	ü	
	to	ý	spare international	
	0 1 1 1	þ	
	1 0 0 0	ü	
	to	ý	spare national	
	1 1 1 0	þ	
	1 1 1 1		reserved for extension.	

	When a global title is used in the called party address, it is suggested that the called party address contain a subsystem number. This serves to simplify message reformatting following global title translation. The subsystem number should be encoded “00000000” when the subsystem number is not known, e.g., before translation.
	Bit 7 of the address indicator octet contains routing information identifying which address element should be used for routing.
	A “0” in bit 7 indicates that routing should be based on the global title in the address.
	A “1” in bit 7 indicates that routing should be based on the destination point code in the MTP routing label and the subsystem number information in the called party address.
	Bit 8 of the address indicator octet is designated for national use.
3.4.2	Address
	The various elements, when provided, occur in the order: point code, subsystem number, global title, as shown in Figure 5/Q.713.

8	7	6	5	4	3	2	1	
Signalling point code								
Subsystem number								
Global title								
FIGURE 5/Q.713
Ordering of address elements
3.4.2.1	Signalling point code
	The signalling point code, when provided, is represented by two octets. Bits 7 and 8 in the second octet are set to zero (see Figure 6/Q.713).

8	7	6	5	4	3	2	1	
								
0	0							
FIGURE 6/Q.713
Signalling point code encoding
3.4.2.2	Subsystem number
	The subsystem number (SSN) identifies an SCCP user function and, when provided, consists of one octet coded as follows:

Bits	8 7 6 5 4 3 2 1		
	0 0 0 0 0 0 0 0		SSN not known/not used	
	0 0 0 0 0 0 0 1		SCCP management	
	0 0 0 0 0 0 1 0		reserved for CCITT allocation	
	0 0 0 0 0 0 1 1		ISDN user part	
	0 0 0 0 0 1 0 0		OMAP	
	0 0 0 0 0 1 0 1		MAP (Mobile Application Part)	
	0 0 0 0 0 1 1 0	ü	
	to	ý	spare	
	1 1 1 1 1 1 1 0	þ	
	1 1 1 1 1 1 1 1		reserved for expansion.	

	Network specific subsystem numbers should be assigned in descending order starting with “11111110”.
3.4.2.3	Global title4)
	The format of the global title is of variable length. Figure 7/Q.913, Figure 9/Q.713, Figure 10/Q.713 and Figure 11/Q.713 show four possible formats for global title.
3.4.2.3.1	Global title indicator = 0001

8	7	6	5	4	3	2	1		
O/E	Nature of address indicator							octet 1	
Address information								octet 2 and further	
FIGURE 7/Q.713
Global title format for indicator 0001
	Bits 1 to 7 of octet 1 contain the nature of address indicator and are coded as follows:

Bits	7 6 5 4 3 2 1		
	0 0 0 0 0 0 0		spare	
	0 0 0 0 0 0 1		subscriber number	
	0 0 0 0 0 1 0		reserved for national use	
	0 0 0 0 0 1 1		national significant number	
	0 0 0 0 1 0 0		international number	
	0 0 0 0 1 0 1	ü	
	   to	ý	spare	
	1 1 1 1 1 1 1	þ	

	Bit 8 of octet 1 contains the odd/even indicator and is coded as follows:
	Bit	8
0	even number of address signals
1	odd number of address signals
	The octets 2 and further contain a number of address signals and possibly a filler as shown in Figure 8/Q.713.

8	7	6	5	4	3	2	1		
2nd address signal				1st address signal				octet 2	
4th address signal				3rd address signal				octet 3	
. . . 									
filler (if necessary)				nth address signal				octet m	
FIGURE 8/Q.713
Address information

	Each address signal is coded as follows:
The application of these codes in actual networks is for further study.	0000	digit 0
	0001	digit 1
	0010	digit 2
	0011	digit 3
	0100	digit 4
	0101	digit 5
	0110	digit 6
	0111	digit 7
	1000	digit 8
	1001	digit 9
	1010	spare
	1011	code 115) 
	1100	code 125)
	1101	spare
	1110	spare
	1111	ST
	In case of an odd number of address signals, a filler code 0000 is inserted after the last address signal.
3.4.2.3.2	Global title indicator = 0010
	Figure 9/Q.713 shows the format of the global title, if the global title indicator equals “0010”.

8	7	6	5	4	3	2	1		
Translation type								octet 1	
Address information								octet 2 and further	
FIGURE 9/Q.713
Global title format for indicator 0010
	The translation type is a one–octet field that is used to direct the message to the appropriate global title translation function.6) Thus, it may be possible for the address information to be translated into different values for and different combinations of DPCs, SSNs and GTs.
	This octet will be coded “00000000” when not used. Translation types for internetwork services will be assigned in ascending order starting with 00000001”. Translation types for network specific services will be assigned in descending order starting with “11111110”. The code “11111111” is reserved for expansion. However, the exact coding of translation types in the international network is for further study. Additional requirements may be placed on this field as a result of further work on Transaction Capabilities and the ISDN User Part.
	In the case of this global title format (0010), the translation type may also imply the encoding scheme, used to encode the address information, and the numbering plan.
3.4.2.3.3	Global title indicator = 0011

8	7	6	5	4	3	2	1		
Translation type								octet 1	
Numbering plan				Encoding scheme				octet 2	
Address information								octet 3 and further	
FIGURE 10/Q.713 
Global title format for indicator 0011
	The translation type is as described in § 3.4.2.3.2.
	The numbering plan is encoded as follows7):

Bits	8 7 6 5		
	0 0 0 0		unknown	
	0 0 0 1		ISDN/Telephony Numbering Plan (Recommendations E.163 and E.164)	
	0 0 1 0		spare	
	0 0 1 1		Data Numbering Plan (Recommendation X.121)	
	0 1 0 0		Telex Numbering Plan (Recommendation F.69)	
	0 1 0 1		Maritime Mobile Numbering Plan (Recommendations E.210, 211)	
	0 1 1 0		Land Mobile Numbering Plan (Recommendation E.212)	
	0 1 1 1		ISDN/Mobile numbering plan (Recommendation E.214)	
	1 0 0 0	ü	
	to	ý	spare	
	1 1 1 0	þ	
	1 1 1 1		reserved	

	The encoding scheme is encoded as follows:

Bits	4 3 2 1		
	0 0 0 0		unknown	
	0 0 0 1		BCD, odd number of digits	
	0 0 1 0		BCD, even number of digits	
	0 0 1 1	ü	
	to	ý	spare	
	1 1 1 0	þ	
	1 1 1 1		reserved.	

	If the encoding scheme is binary coded decimal, the global title value, starting from octet 3, is encoded as shown in Figure 8/Q.713.
3.4.2.3.4	Global title indicator = 0100

8	7	6	5	4	3	2	1		
Translation type								octet 1	
Numbering plan				Encoding scheme				octet 2	
Spare	Nature of address indicator							octet 3	
Address information								octet 4 and further	
FIGURE 11/Q.713
Global title format for indicator 0100
	The field “translation type” is as described in § 3.4.2.3.2. The fields “numbering plan” and “encoding scheme” are as described in § 3.4.2.3.3. The field “nature of address indicator” is as described in § 3.4.2.3.1.
	If the encoding scheme is binary coded decimal, the global title value, starting from octet 4, is encoded as shown in Figure 8/Q.713.
3.5	Calling party address
	The “calling party address” is a variable length parameter. Its structure is the same as the “called party address”.
	When the calling party address is a mandatory parameter but is not available or must not be sent, the calling party address parameter only consists of the address indicator octet, where bits 1 to 7 are coded all zeros.
3.6	Protocol class
	The “protocol class” parameter field is a four bit field containing the protocol class.
	Bits 1–4 are coded as follows:
	4321
	0000	class 0
	0001	class 1
	0010	class 2
	0011	class 3
	When bits 1–4 are coded to indicate a connection–oriented–protocol class (class 2, class 3), bits 5–8 are spare.

	When bits 1–4 are coded to indicate a connectionless protocol class (class 0, class 1), bits 5–8 are used to specify message handling as follows:

Bits	8 7 6 5		
	0 0 0 0		no special options	
	0 0 0 1	ü	
	to	ý	spare	
	0 1 1 1	þ	
	1 0 0 0		return message on error	
	1 0 0 1	ü	
	to	ý	spare	
	1 1 1 1	þ	

3.7	Segmenting/reassembling
	The “segmenting/reassembling” parameter field is a one octet field and is structured as follows:

8	7	6	5	4	3	2	1	
reserve							M	

	Bits 8–2 are spare.
	Bit 1 is used for the More Data indication and is coded as follows:
	0 = no more data
	1 = more data
3.8	Receive sequence number
	The “receive sequence number” parameter field is a one octet field and is structured as follows:

8	7	6	5	4	3	2	1	
P(R)							/	

	Bits 8–2 contain the receive sequence number P(R) used to indicate the sequence number of the next expected message. P(R) is binary coded and bit 2 is the LSB.
	Bit 1 is spare.

3.9	Sequencing/segmenting
	The sequencing/segmenting parameter field consists of two octets and is structured as follows:

	8	7	6	5	4	3	2	1	
octet 1	P(S)							/	
octet 2	P(R)							M	

	Bits 8–2 of octet 1 are used for indicating the send sequence number P(S). P(S) is binary coded and bit 2 is the LSB.
	Bit 1 of octet 1 is spare.
	Bits 8–2 of octet 2 are used for indicating the receive sequence number P(R). P(R) is binary coded and bit 2 is the LSB.
	Bit 1 of octet 2 is used for the More Data indication and is coded as follows:
0 = no more data
1 = more data
	The sequencing/segmenting parameter field is used exclusively in protocol class 3.
3.10	Credit
	The “credit” parameter field is a one–octet field used in the protocol classes which include flow control functions. It contains the window size value coded in pure binary.
3.11	Release cause
	The release cause parameter field is a one–octet field containing the reason for the release of the connection.
	The coding of the release cause field is as follows:

Bits	8 7 6 5 4 3 2 1		
	0 0 0 0 0 0 0 0		end user originated	
	0 0 0 0 0 0 0 1		end user congestion	
	0 0 0 0 0 0 1 0		end user failure	
	0 0 0 0 0 0 1 1		SCCP user originated	
	0 0 0 0 0 1 0 0		remote procedure error	
	0 0 0 0 0 1 0 1		inconsistent connection data	
	0 0 0 0 0 1 1 0		access failure	
	0 0 0 0 0 1 1 1		access congestion	
	0 0 0 0 1 0 0 0		subsystem failure	
	0 0 0 0 1 0 0 1		subsystem congestion8)	
	0 0 0 0 1 0 1 0		network failure	
	0 0 0 0 1 0 1 1		network congestion	
	0 0 0 0 1 1 0 0		expiration of reset timer	
	0 0 0 0 1 1 0 1		expiration of receive inactivity timer	
	0 0 0 0 1 1 1 0		not obtainable	
	0 0 0 0 1 1 1 1		unqualified	
	0 0 0 1 0 0 0 0	ü	
	to	ý	spare	
	1 1 1 1 1 1 1 1	þ	

	Note – A more comprehensive list of causes covering X.96 call progress information is for further study.

3.12	Return cause
	In the Unitdata Service message, the «return cause» parameter field is a one octet field containing the reason for message return. Bits 1–8 are coded as follows:

Bits	8 7 6 5 4 3 2 1		
	0 0 0 0 0 0 0 0		no translation for an address of such nature	
	0 0 0 0 0 0 0 1		no translation for this specific address	
	0 0 0 0 0 0 1 0		subsystem congestion9)	
	0 0 0 0 0 0 1 1		subsystem failure	
	0 0 0 0 0 1 0 0		unequipped user	
	0 0 0 0 0 1 0 1		network failure	
	0 0 0 0 0 1 1 0		network congestion	
	0 0 0 0 0 1 1 1		unqualified	
	0 0 0 0 1 0 0 0	ü	
	to	ý	spare	
	1 1 1 1 1 1 1 1	þ	

3.13	Reset cause
	The “reset cause” parameter field is a one octet field containing the reason for the resetting of the connection.
	The coding of the reset cause field is as follows:

Bits	8 7 6 5 4 3 2 1		
	0 0 0 0 0 0 0 0		end user originated	
	0 0 0 0 0 0 0 1		SCCP user originated	
	0 0 0 0 0 0 1 0		message out of order – incorrect P(S)	
	0 0 0 0 0 0 1 1		message out of order – incorrect P(R)	
	0 0 0 0 0 1 0 0		remote procedure error – message out of window	
	0 0 0 0 0 1 0 1		remote procedure error – incorrect P(S) after (re)initialization	
	0 0 0 0 0 1 1 0		remote procedure error – general	
	0 0 0 0 0 1 1 1		remote end user operational	
	0 0 0 0 1 0 0 0		network operational	
	0 0 0 0 1 0 0 1		access operational	
	0 0 0 0 1 0 1 0		network congestion	
	0 0 0 0 1 0 1 1		not obtainable	
	0 0 0 0 1 1 0 0		unqualified	
	0 0 0 0 1 1 0 1	ü	
	to	ý	spare	
	1 1 1 1 1 1 1 1	þ	
3.14	Error cause
	The “error cause” parameter field is a one octet field containing the indication of the exact protocol error.
	The coding of the error cause field is as follows:

Bits	8 7 6 5 4 3 2 1		
	0 0 0 0 0 0 0 0	local reference number (LRN) mismatch – unassigned destination LRN	
	0 0 0 0 0 0 0 1	local reference number (LRN) mismatch – inconsistent source LRN	
	0 0 0 0 0 0 1 0	point code mismatch10)	
	0 0 0 0 0 0 1 1	service class mismatch	
	0 0 0 0 0 1 0 0	unqualified	
	0 0 0 0 0 1 0 1	ü	
	to	ý	spare	
	1 1 1 1 1 1 1 1	þ	

3.15	Refusal cause
	The refusal cause parameter field is a one octet field containing the reason for the refusal of the connection.
	The coding of the refusal cause field is as follows:

Bits	8 7 6 5 4 3 2 1		
	0 0 0 0 0 0 0 0		end user originated	
	0 0 0 0 0 0 0 1		end user congestion	
	0 0 0 0 0 0 1 0		end user failure	
	0 0 0 0 0 0 1 1		SCCP user originated	
	0 0 0 0 0 1 0 0		destination address unknown	
	0 0 0 0 0 1 0 1		destination inaccessible	
	0 0 0 0 0 1 1 0		network resource – QOS not available/non–transient	
	0 0 0 0 0 1 1 1		network resource – QOS not available/transient	
	0 0 0 0 1 0 0 0		access failure	
	0 0 0 0 1 0 0 1		access congestion	
	0 0 0 0 1 0 1 0		subsystem failure	
	0 0 0 0 1 0 1 1		subsystem congestion11)	
	0 0 0 0 1 1 0 0		expiration of the connection establishment timer	
	0 0 0 0 1 1 0 1		incompatible user data	
	0 0 0 0 1 1 1 0		not obtainable	
	0 0 0 0 1 1 1 1		unqualified	
	0 0 0 1 0 0 0 0	ü	
	to	ý	spare	
	1 1 1 1 1 1 1 1	þ	
	Note 1 – The inclusion of the routing failure causes as specified for the “return cause” parameter in Recommendation Q.713, § 3.12, is for further study.
	Note 2 – A more comprehensive list of causes covering CCITT Recommendation X.96 call progress information is for further study.
3.16	Data
	The “data” parameter field is a variable length field containing SCCP–user data to be transferred transparently between the SCCP user functions.
4	SCCP messages and codes
4.1	General
4.1.1	In the following sections, the format and coding of the SCCP messages is specified.
	For each message a list of the relevant parameters is given in a tabular form.
4.1.2	For each parameter the table also includes:
–	a reference to the section where the formatting and coding of the parameter content is specified;
–	the type of the parameter. The following types are used in the tables:
F	= mandatory fixed length parameter;
V	= mandatory variable length parameter;
O	= optional parameter of fixed or variable length;
–	the length of the parameter. The value in the table includes:
–	for type F parameters the length, in octets, of the parameter content;
–	for type V parameters the length, in octets, of the length indicator and of the parameter content; (The minimum and the maximum length are indicated.)
–	for type O parameters the length, in octets, of the parameter name, length indicator and parameter content. (For variable length parameters the minimum and maximum length is indicated.)
4.1.3	For each message the number of pointers included is also specified.
4.1.4	For each message type, type F parameters and the pointers for the type V parameters must be sent in the order specified in the following tables.
4.2	Connection request (CR)
	The CR message contains:
–	the routing label,
–	2 pointers,
–	the parameters indicated in Table 3/Q.713.
4.3	Connection confirm (CC)
	The CC message contains:
–	the routing label,
–	1 pointer,
–	the parameters indicated in Table 4/Q.713.
4.4	Connection refused (CREF)
	The message contains:
–	the routing label,
–	1 pointer,
–	the parameters indicated in Table 5/Q.713.
4.5	Released (RLSD)
	The RLSD message contains:
–	the routing label,
–	1 pointer,
–	the parameters indicated in Table 6/Q.713.
4.6	Release complete (RLC)
	The RLC message contains:
–	the routing label,
–	no pointers,
–	the parameters indicated in Table 7/Q.713.
4.7	Data form 1 (DT1)
	The DT1 message contains:
–	the routing label,
–	1 pointer,
–	the parameters indicated in Table 8/Q.713.
4.8	Data form 2 (DT2)
	The DT2 message contains:
–	the routing label,
–	1 pointer,
–	the parameters indicated in Table 9/Q.713.
TABLE 3/Q.713
Message type: Connection request
Parameter	§	Type (F V O)	Length (octets)	
Message type code	2.1 	F	1	
Source local reference	3.3 	F	3	
Protocol class	3.6 	F	1	
Called party address	3.4 	V	3 minimum	
Credit	3.10	O	3	
Calling party address	3.5 	O	4 minimum	
Data	3.16	O	3 – 130	
End of optional parameters	3.1 	O	1	

TABLE 4/Q.713
Message type: Connection confirm
Parameter	§	Type (F V O)	Length (octets)	
Message type	2.1 	F	1	
Destination local reference	3.2 	F	3	
Source local reference	3.3 	F	3	
Protocol class	3.6 	F	1	
Credit	3.10	O	3	
Called party address	3.4 	O	4 minimum	
Data	3.16	O	3 – 130	
End of optional parameter	3.1 	O	1	

TABLE 5/Q.713
Message type: Connection refused
Parameter	§	Type (F V O)	Length (octets)	
Message type	2.1 	F	1	
Destination local reference	3.2 	F	3	
Refusal cause	3.15	F	1	
Called party address	3.4 	O	4 minimum	
Data	3.16	O	3 – 130	
End of optional parameter	3.1 	O	1	

TABLE 6/Q.713
Message type: Released
Parameter	§	Type (F V O)	Length (octets)	
Message type	2.1	F	1	
Destination local reference	3.2	F	3	
Source local reference	3.3	F	3	
Release cause	3.11	F	1	
Data	3.16	O	3 – 130	
End of optional parameter	3.1	O	1	

TABLE 7/Q.713
Message type: Release complete
Parameter	§	Type (F V O)	Length (octets)	
Message type	2.1	F	1	
Destination local reference	3.2	F	3	
Source local reference	3.3	F	3	

TABLE 8/Q.713
Message type: Data form 1
Parameter	§	Type (F V O)	Length (octets)	
Message type	2.1 	F	1	
Destination local reference	3.2 	F	3	
Segmenting/reassembling	3.7 	F	1	
Data	3.16	V	2 – 256	

TABLE 9/Q.713
Message type: Data form 2
Parameter	§	Type (F V O)	Length (octets)	
Message type	2.1 	F	1	
Destination local reference	3.2 	F	3	
Sequencing/Segmenting	3.9 	F	2	
Data	3.16	V	2 – 256	

4.9	Data acknowledgement (AK)
	The AK message contains:
–	the routing label,
–	no pointers,
–	the parameters indicated in Table 10/Q.713.
TABLE 10/Q.713
Message type: Data acknowledgement
Parameter	§	Type (F V O)	Length (octets)	
Message type	2.1 	F	1	
Destination local reference	3.2 	F	3	
Receive sequence number	3.8 	F	1	
Credit	3.10	F	1	
4.10	Unitdata (UDT)
	The UDT message contains:
–	the routing label,
–	3 pointers,
–	the parameters indicated in Table 11/Q.713.
TABLE 11/Q.713
Message type: Unitdata
Parameter	§	Type (F V O)	Length (octets)	
Message type	2.1 	F	1	
Protocol class	3.6 	F	1	
Called party address	3.4 	V	3 minimum	
Calling party address	3.5 	V	2 minimum	
Data	3.16	V	2 – X a)	
a)	Due to the ongoing studies on the SCCP called and calling party address, the maximum length of this parameter needs further study. It is also noted that the transfer of up to 255 octets of user data is allowed when the SCCP called and calling party address do not include global title.

4.11	Unitdata service (UDTS)
	The UDTS message contains:
–	the routing label,
–	3 pointers,
–	the parameters indicated in Table 12/Q.713.
TABLE 12/Q.713
Message type: Unitdata service
Parameter	§	Type (F V O)	Length (octets)	
Message type	2.1 	F	1	
Return cause	3.12	F	1	
Called party address	3.4 	V	3 minimum	
Calling party address	3.5 	V	2 minimum	
Data	3.16	V	2 – X a)	
a)	See a) Table 11/Q.713.
4.12	Expedited data (ED)
	The ED message contains:
–	the routing label,
–	1 pointer,
–	the parameters indicated in Table 13/Q.713.
TABLE 13/Q.713
Message type: Expedited data
Parameter	§	Type (F V O)	Length (octets)	
Message type	2.1 	F	1	
Destination local reference	3.2 	F	3	
Data	3.16	V	2 – 33	

4.13	Expedited data acknowledgement (EA)
	The EA message contains:
–	the routing label,
–	no pointers,
–	the parameters indicated in Table 14/Q.713.
TABLE 14/Q.713
Message type: Expedited data acknowledgement
Parameter	§	Type (F V O)	Length (octets)	
Message type	2.1	F	1	
Destination local reference	3.2	F	3	
4.14	Reset request (RSR)
	The RSR message contains:
–	the routing label,
–	1 pointer,
–	the parameters indicated in Table 15/Q.713.
TABLE 15/Q.713
Message type: Reset request
Parameter	§	Type (F V O)	Length (octets)	
Message type	2.1 	F	1	
Destination local reference	3.2 	F	3	
Source local reference	3.3 	F	3	
Reset cause	3.13	F	1	

4.15	Reset confirm (RSC)
	The RSC message contains:
–	the routing label,
–	no pointers,
–	the parameters indicated in Table 16/Q.713.
TABLE 16/Q.713
Message type: Reset confirmation
Parameter	§	Type (F V O)	Length (octets)	
Message type	2.1	F	1	
Destination local reference	3.2	F	3	
Source local reference	3.3	F	3	
4.16	Protocol data unit error (ERR)
	The ERR message contains:
–	the routing label,
–	1 pointer,
–	the parameters indicated in Table 17/Q.713.
TABLE 17/Q.713
Message type: Protocol data unit error
Parameter	§	Type (F V O)	Length (octets)	
Message type	2.1 	F	1	
Destination local reference	3.2 	F	3	
Error cause	3.14	F	1	

4.17	Inactivity test (IT)
	The IT message contains:
–	the routing label,
–	no pointers,
–	the parameters indicated in Table 18/Q.713.
TABLE 18/Q.713
Message type: Inactivity test
Parameter	§	Type (F V O)	Length (octets)	
Message type	2.1	F	1	
Destination local reference	3.2	F	3	
Source local reference	3.3	F	3	
Protocol class	3.6	F	1	
Sequencing/segmenting a)	3.9	F	2	
Credit a)	3.10	F	1	
a)	Information in these parameter fields reflect those values sent in the last data Form 2 or Data acknowledgement message. They are ignored if the protocol class parameter indicates class 2.
5	SCCP Management messages and codes
5.1	General
	SCCP Management (SCMG) messages are carried using the connectionless service of the SCCP. When transferring SCMG messages, class 0 is requested with the “discard message on error” option. SCCP management message parts are provided in the “data” parameter of the Unitdata message.
	The Unitdata message contains:
–	the routing label,
–	3 pointers,
–	the parameters indicated in Table 19/Q.713.
	Descriptions of the various parts are contained in the following sections.
TABLE 19/Q.713
SCCP management message format
Parameter	§	Type (F V O)	Length (octets)	
Message type 
(= Unitdata)	2.1	F	1	
Protocol class 
(= Class 0, no return)	3.6	F	1	
Called party address 
(SSN = SCCP management)	3.4	V	3 minimum	
Calling party address 
(SSN = SCCP management)	3.5	V	3 minimum a)	
Data 
(Data consists of an SCMG message with form as in Table 22/Q.713)	3.16	V	6	
a)	SSN is always present.
5.1.1	SCMG format identifier
	The SCMG format identifier consists of a one–octet field, which is mandatory for all SCMG messages. The SCMG format identifier uniquely defines the function and format of each SCMG message. The allocation of SCMG format identifiers is shown in Table 20/Q.713.
TABLE 20/Q.713
SCMG format identifiers
Message	Code 87654321	
SSA Subsystem–Allowed	00000001	
SSP Subsystem–Prohibited	00000010	
SST Subsystem–Status–Test	00000011	
SOR Subsystem–Out–of–Service–Request	00000100	
SOG Subsystem–Out–of–Service–Grant	00000101	

5.1.2	Formatting principles
	The formatting principles used for SCCP messages, as described in §§ 1.3, 1.4, 1.5, 1.6, 2.2 and 2.3 apply to SCMG messages.
5.2	SCMG message parameters
	SCMG parameter name codes are given in Table 21/Q.713 with reference to the subsections in which they are described. Presently, these parameter name codes are not used since all SCMG messages contain mandatory fixed parameters only.
TABLE 21/Q.713
SCMG parameter name codes
Parameter name	§	Parameter name code 87654321	
End of optional parameters	5.2.1	00000000	
Affected SSN	5.2.2	00000001	
Affected PC	5.2.3	00000010	
Subsystem multiplicity indicator	5.2.4	00000011	
5.2.1	End of optional parameters
	The “end of optional parameters” parameter field consists of a single octet containing all zeros.
5.2.2	Affected SSN
	The “affected subsystem number (SSN)” parameter field consists of one octet coded as directed for the called party address field, § 3.4.2.1.
5.2.3	Affected PC
	The “affected signalling point code (PC)” parameter field is represented by two octets which are coded as directed for the called party address field, § 3.4.2.2.
5.2.4	Subsystem multiplicity indicator
	The “subsystem multiplicity indicator” parameter field consists of one octet coded as shown in Figure 12/Q.713.

8	7	6	5	4	3	2	1	
spare						SMI		
FIGURE 12/Q.713
Subsystem multiplicity indicator format

	The coding of the SMI field is as follows:
	Bits	21
		00	affected subsystem multiplicity unknown
		01	affected subsystem is solitary
		10	affected subsystem is duplicated
		11	spare
	Bits 3–8 are spare.
5.3	SCMG messages
	Presently, all SCMG messages contain mandatory fixed parameters only. Each SCMG message contains:
–	0 pointers
–	the parameters indicated in Table 22/Q.713.
TABLE 22/Q.713
SCMG Message
Parameter	§	Type (F V O)	Length (octets)	
SCMG format identifier
(Message type code)	5.1.1	F	1	
Affected SSN	5.2.2	F	1	
Affected PC	5.2.3	F	2	
Subsystem multiplicity indicator	5.2.4	F	1	
ANNEX A
(to Recommendation Q.713)
Mapping for cause parameter values
A.1	Introduction
	During connection refusal/release/reset, the SCCP and its users could take necessary corrective actions, if any, only upon relevant information available to them. Thus, it would be very helpful if those information could be conveyed correctly.
	During connection release, the “release cause” parameter in the Released (RLSD) message and the N–DISCONNECT primitive (with parameters “originator” and “reason”) are used together to convey those information on the initiator and the cause of the connection release. In addition, the N–DISCONNECT primitive is also used together with the “refusal cause” parameter in the Connection Refused (CREF) message to convey those information during connection refusal. During connection reset, the “reset cause” parameter in the Reset Request (RSR) message and the N–RESET primitive (with parameters “originator” and “reason”) are used together similarly.
	In order to convey those information correctly, this Annex provides a guideline for the mapping of values between the cause parameters and the corresponding N–primitive parameters during various scenarios.

A.2	Connection refusal
	Table A–1/Q.713 describes the mapping of values between the “refusal cause” parameter (§ 3.15, Rec. Q.713) and the “originator”, “reason” parameters in the N–DISCONNECT primitive (§ 2.1.1.2.4, Rec. Q.711).
A.3	Connection release
	Table A–2/Q.713 describes the mapping of values between the “release cause” parameter (§ 3.11, Rec. Q.713) and the “originator”, “reason” parameters in the N–DISCONNECT primitive (§ 2.1.1.2.4, Rec. Q.711).
A.4	Connection reset
	Table A–3/Q.713 describes the mapping of values between the “reset cause” parameter (§ 3.13, Rec. Q.713) and the “originator”, “reason” parameters in the N–RESET primitive (§ 2.1.1.2.3, Rec. Q.711).

TABLE A–1/Q.713
Mapping during connection refusal
CREF Message		N–DISCONNECT primitive		
Code	Refusal cause	Reason	Originator	
00000000	end user originated	connection refusal – end user originated	NSU	
00000001	end user congestion	connection refusal – end user congestion	NSU	
00000010	end user failure	connection refusal – end user failure	NSU	
00000011	SCCP user originated	connection refusal – SCCP user originated	NSU	
00000100	destination address unknown	connection refusal – destination address unknown (non–transient condition)	NSP	
00000101	destination inaccessible	connection refusal – destination inaccessible/transient condition	NSP	
00000110	network resource – QOS unavailable/non–transient	 connection refusal – QOS unavailable/non–transient condition	NSP a)	
00000111	network resource – QOS unavailable/transient	 connection refusal – QOS unavailable/transient condition	NSP a)	
00001000	access failure	connection refusal – access failure	NSU	
00001001	access congestion	connection refusal – access congestion	NSU	
00001010	subsystem failure	connection refusal – destination inaccessible/non–transient condition	NSP	
00001011	subsystem congestion	connection refusal – subsystem congestion	NSU	
00001100	expiration of connection estimated timer	connection refusal – reason unspecified/transient	NSP a)	
00001101	inconsistent user data	connection refusal – incompatible information in NSDU	NSU	
00001110	not obtainable	connection refusal – reason unspecified/transient	NSP a)	
00001110	not obtainable	connection refusal – undefined	undefined	
00001111	unqualified	connection refusal – reason unspecified/transient	NSP a)	
00001111	unqualified	connection refusal – undefined	undefined	
NSU	Network Service User
NSP	Network Service Provider
a)	Only those cases will be applicable if the SCCP originates the refusal procedure in response to REQUEST interface element.
TABLE A–2/Q.713
Mapping during connection release
RLSD Message		N–DISCONNECT primitive		
Code	Release cause	Reason	Originator	
00000000	end user originated	disconnection – normal condition	NSU	
00000001	end user congestion	disconnection – end user congestion	NSU	
00000010	end user failure	disconnection – end user failure	NSU	
00000011	SCCP user originated	disconnection – SCCP user originated	NSU	
00000100	remote procedure error	disconnection – abnormal condition of transient nature	NSP	
00000101	inconsistent connection data	disconnection – abnormal condition of transient nature	NSP	
00000110	access failure	disconnection – access failure	NSU	
00000111	access congestion	disconnection – access congestion	NSU	
00001000	subsystem failure	disconnection – abnormal condition of non–transient nature	NSP	
00001001	subsystem congestion	disconnection – subsystem congestion	NSU	
00001010	network failure	disconnection – abnormal condition of non–transient nature	NSP	
00001011	network congestion	disconnection – abnormal condition of transient nature	NSP	
00001100	expiration of reset timer	disconnection – abnormal condition of transient nature	NSP	
00001101	expiration of receive inactivity timer	disconnection – abnormal condition of transient nature	NSP	
00001110	not obtainable a)	disconnection – undefined	NSP	
00001110	not obtainable a)	disconnection – undefined	undefined	
00001111	unqualified	disconnection – abnormal condition	NSU	
00001111	unqualified	disconnection – undefined	NSP	
00001111	unqualified	disconnection – undefined	undefined	
NSU	Network Service User
NSP	Network Service Provider
a)	The need for this value is for further study.
TABLE A–3/Q.713
Mapping during connection reset
RSR Message		N–RESET primitive		
Code	Reset cause	Reason	Originator	
00000000	end user originated	reset – user synchronization	NSU	
00000001	SCCP user originated	reset – user synchronization	NSU	
00000010	message out of order – incorrect P(S)	reset – unspecified	NSP	
00000011	message out of order – incorrect P(R)	reset – unspecified	NSP	
00000100	remote procedure error – message out of window	reset – unspecified	NSP	
00000101	remote procedure error – incorrect P(S) after initialization	reset – unspecified	NSP	
00000110	remote procedure error – general	reset – unspecified	NSP	
00000111	remote end user operational	reset – user synchronization	NSU	
00001000	network operational	reset – unspecified	NSP	
00001001	access operational	reset – user synchronization	NSU	
00001010	network congestion	reset – network congestion	NSP	
00001011	not obtainable a)	reset – unspecified	NSP	
00001011	not obtainable a)	reset – undefined	undefined	
00001100	unqualified	reset – unspecified	NSP	
00001100	unqualified	reset – undefined	undefined	
NSU	Network Service User
NSP	Network Service Provider
a)	The need for this value is for further study.