fRecommendation Q.711
FUNCTIONAL DESCRIPTION OF THE SIGNALLING CONNECTION CONTROL PART
1	Introduction
1.1	General
	The Signalling Connection Control Part (SCCP) provides additional functions to the Message Transfer Part (MTP) to cater for both connectionless as well as connection–oriented network services to transfer circuit related and non–circuit related signalling information and other type of information between exchanges and specialized centres in telecommunication networks (e.g., for management and maintenance purposes) via a Signalling System No. 7 network.
	A functional block situated above the Message Transfer Part, the latter being described in Recommendations Q.701 through Q.707, performs the functions and procedures of the SCCP. Thus the Message Transfer Part remains unchanged (Figure 1/Q.711). The combination of the MTP and the SCCP is called Network Service Part (NSP).
	The Network Service Part meets the requirements for Layer 3 services as defined in the OSI–Reference Model, CCITT Recommendation X.200.
1.2	Objectives
	The overall objectives of the Signalling Connection Control Part are to provide the means for:
a)	logical signalling connections within the CCITT No. 7 Signalling Network;
b)	a transfer capability for Signalling Data Units with or without the use of logical signalling connections.
	Functions of the SCCP are also used for the transfer of circuit related and call related signalling information of the ISDN User Part with or without setup of end–to–end logical signalling connections. These functions are described in Recommendations Q.714 and Q.764. Figure 1/Q.711 illustrates the embedding of the SCCP within the CCITT No. 7 signalling system.
1.3	General characteristic
1.3.1	Technique of description
	The Signalling Connection Control Part (SCCP) is described in terms of:
–	services provided by the SCCP,
–	services assumed from the MTP,
–	functions of the SCCP.
	The functions of the SCCP are performed by means of the SCCP–protocol between two systems which provide the NSP–service to the upper layers.
	The service interfaces to the upper layers and to the MTP are described by means of primitives and parameters, as recommended in CCITT Recommendation X.200. Figure 2/Q.711 illustrates the relationship between the SCCP protocol and the adjacent services.
Figure 1/Q.711 - T1113220-88

Figure 2/Q.711 - T1113230-88

1.3.2	Primitives
	Primitives consist of commands and their respective responses associated with the services requested of the SCCP and of the MTP, see Figure 3/Q.711. The general syntax of a primitive is specified in Recommendation Q.700.
Figure 3/Q.711 - T1113240-88

1.3.3	Peer–to–peer communication
	Exchange of information between two peers of the SCCP is performed by means of a protocol. The protocol is a set of rules and formats by which the control information (and user data) is exchanged between the two peers. The protocol caters for:
–	the setup of logical signalling connections,
–	the release of logical signalling connections,
–	the transfer of data with or without logical signalling connections.
	A signalling connection is modelled in the abstract by a pair of queues. The protocol elements are objects on that queue added by the origination SCCP user and removed by the destination SCCP user. Each queue represents a flow control function. Figure 4/Q.711 illustrates the modes described above. (Model for the connectionless service is for further study.)
Figure 4/Q.711 - T1113250-88

1.3.4	Contents of the Recommendations Series Q.71x
	Recommendation Q.711 contains a general description of the services provided by the MTP, the services provided by the SCCP and the functions within the SCCP.
	Recommendation Q.712 defines the set of protocol elements and their embedding into messages.
	Recommendation Q.713 describes the formats and codes used for the SCCP messages.
	Recommendation Q.714 is a detailed description of the SCCP procedures as a protocol specification.
	Recommendation Q.716 defines and specifies values for the SCCP performance parameters, including quality of service parameters and internal parameters.
2	Services provided by the SCCP
	The overall set of services is grouped into:
–	connection–oriented services,
–	connectionless services.
	Four classes of service are provided by the SCCP protocol, two for connectionless services and two for connection–oriented services.
	The four classes are:
	0	Basic connectionless class
	1	Sequenced (MTP) connectionless class
	2	Basic connection–oriented class
	3	Flow control connection–oriented class

2.1	Connection–oriented services
	A distinction has to be made between:
–	temporary signalling connections,
–	permanent signalling connections.
	Temporary signalling connection establishment is initiated and controlled by the SCCP user. Temporary signalling connections are comparable with dialled telephone connections.
	Permanent signalling connections are established and controlled by the local (or remote) O&M–function or by the management function of the node and they are provided for the SCCP user on a semipermanent basis. They can be compared with leased telephone lines.
2.1.1	Temporary signalling connections
2.1.1.1	Description
	The control of a signalling connection is divided into the following phases:
–	connection establishment phase,
–	data transfer phase,
–	connection release phase.
2.1.1.1.1	Connection establishment phase
	Connection establishment procedures provide the mechanism for establishing temporary signalling connections between users of the SCCP.
	A signalling connection between two SCCP users may consist of one or more connection sections.
	During connection establishment, routing functions are provided by the SCCP, in addition to those provided by the MTP.
	At intermediate nodes, SCCP routing determines whether a signalling connection should be realized by one connection or by several concatenated connection sections.
	The ISDN UP may provide the routing of the request for the setup of a connection section.
	The connection refusal procedure is invoked if the SCCP is unable to establish a signalling connection.
2.1.1.1.2	Data transfer phase
	The data transfer service provides for an exchange of user data, called Network Service Data Units (NSDU), in either direction or in both directions simultaneously on a signalling connection.
	A SCCP message between two peer consists of:
–	Network Protocol Control Information (NPCI),
–	Network Service Data Unit (NSDU).
	The Network Protocol Control Information supports the joint operating of the SCCP–peer entities within the two nodes communicating with each other. It contains a connection reference parameter which allocates the message to a certain signalling connection.
	The Network Service Data Unit contains a certain amount of information from the SCCP user which has to be transferred between two nodes using the service of the SCCP.
	Network Protocol Control Information and Network Service Data Unit are put together and transferred as a message (Figure 5/Q.711). If the size of user data is too big to be transferred within one message, user data are segmented into a number of portions. Each portion is mapped to a separate message, consisting of the NPCI and a NSDU (Figure 6/Q.711).
	The data transfer service caters for sequence control and flow control depending on the quality of service required by the SCCP user (two different classes of the connection–oriented service are provided by the protocol; see Recommendation Q.714).
Figure 5/Q.711 - T1113260-88

Figure 6/Q.711 - T1113270-88

2.1.1.1.3	Connection release phase
	Connection release procedures provide the mechanism for disconnecting temporary signalling connections between users of the SCCP.
2.1.1.2	Network service primitives and parameters
2.1.1.2.1	Overview
	Table 1/Q.711 gives an overview of the primitives to the upper layers and the corresponding parameters for the (temporary) connection oriented network service. Figure 7/Q.711 shows an overview state transition diagram for the sequence of primitives at a connection endpoint, refer to Recommendation X.213, Network Layer Service Definition of Open Systems Interconnection for CCITT application.
	A more detailed description for the primitives and their parameters is given in the following chapters.
TABLE 1/Q.711
Network service primitives for connection–oriented services
Primitives			
Generic name	Specific name	Parameters	
N–CONNECT	Request	Called address	
	Indication	Calling address	
	Response	Responding address	
	Confirmation	Receipt confirmation election	
		Expedited data selection	
		Quality of service parameter set	
		User data	
		Connection identification a)	
N–DATA	Request	Confirmation request	
	Indication	User data	
		Connection identification a)	
N–EXPEDITED DATA	Request	User data	
	Indication	Connection identification a)	
N–DATA ACKNOWLEDGE (for further study)	Request	Connection identification a)	
	Indication		
N–DISCONNECT	Request	Originator	
	Indication	Reason	
		User data	
		Responding address	
		Connection identification a)	
N–RESET	Request	Originator	
	Indication	Reason	
	Response	Connection identification a)	
	Confirmation		
a)	In Recommendation X.213, § 5.3, this parameter is implicit.

Figure 7/Q.711 - T1113281-88

2.1.1.2.2	Connection establishment phase
	A SCCP user (calling user) initiates the setup of the connection by means of the primitive “N–CONNECT request” to the SCCP. The SCCP entity evaluates the primitive and adds the protocol control information. The SCCP message (consisting of the protocol control information (PCI) and possibly an NSDU) is transmitted by means of the MTP–services to the remote peer entity of the SCCP. It evaluates and strips the PCI and sends a primitive “N–CONNECT indication” to the local SCCP user. On both ends of the connection the status “pending” is assumed.
	The called SCCP user answers with the primitive “N–CONNECT response” to the local SCCP, which sends the response SCCP message including PCI to the calling SCCP. The calling SCCP sends the primitive “N–CONNECT confirmation” to the calling SCCP–User. The connection is now ready for data transfer.
	The four types of N–CONNECT, the request, the indication, the response and the confirmation contain the parameters as shown and further described in Table 2/Q.711.
TABLE 2/Q.711
Parameters of the primitive N–CONNECT
	Primitive				
Parameter	N–CONNECT request	N–CONNECT indication	N–CONNECT response	N–CONNECT confirmation	
Called address	X	X d)			
Calling address	X d)	X			
Responding address			X	X	
Receipt confirmation election a)	X	X	X	X	
Expedited data selection	X	X	X	X	
Quality of service parameter set	X	X	X	X	
User data b)	X	X	X	X	
Connection identification c)	X	X	X	X	
X	Parameter present within the primitive.
a)	Parameter conditionally present.
b)	User data within the connection primitives are defined as a provider option (refer to CCITT Recommendation X.213).
c)	This parameter is not in Recommendation X.213 and is for further study.
d)	This parameter may be implicitly associated with the SCCP service access point at which this primitive is issued.

	The parameters “Called address/Calling address” convey addresses identifying the destination/source of a communication. There are three types of addresses:
	Global Title,
	Subsystem Number,
	Signalling Point Code.
	The Global Title is an address such as dialled digits which does not explicitly contain information that would allow routing in the signalling network, i.e., a translation function is required. The Subsystem Number is an identification of a specific user function within a certain signalling point (SP), like the ISDN–User Part, the SCCP–Management, etc.
	The parameter “Responding address” indicates to which destination the connection has been established or refused.
	The “Responding address” parameter in the N–CONNECT primitive conveys the address of the service access point to which the signalling connection has been established. Under certain circumstances (e.g. call redirection, generic addressing, etc.), the value of this parameter may be different from the “Called address” in the corresponding N–CONNECT request. Such facilities that cause the difference are for further study.
	The “Responding address” parameter is present in the N–DISCONNECT primitive only in the case where the primitive is used to indicate rejection of a signalling connection establishment attempt by an SCCP user function. The parameter conveys the address of the service access point from which the N–DISCONNECT–request was issued and under circumstances like that mentioned above the “Responding address” may be different from the “Called address” in the corresponding N–CONNECT request primitive.
	The parameter “Receipt confirmation selection” indicates the use/availability of the receipt confirmation service. The need for such a service is for further study.
	The parameter “Expedited data selection” may be used to indicate during setup whether expedited data can be transferred via the connection. A negotiation will be performed between SCCP users, local and remote.
	The Quality of Service parameters are used during call setup to negotiate the protocol class for the connection and, if applicable, the flow control window size.
	The N–CONNECT primitives may or may not contain user data.
	The parameter “Connection identification” is used to allocate a primitive to a certain connection.
	In principle, the connection establishment has to be completed (i.e., data transfer status has to be reached) before sending or receiving data messages. If data messages arrive at the calling user before the connection establishment is finished these data messages are discarded.
	In addition, user data can also be transferred to/from the SCCP within the primitives N–CONNECT and N–DISCONNECT.
2.1.1.2.3	Data transfer phase
	During this phase four different primitives may occur:
a)	N–DATA (Table 3/Q.711),
b)	N–EXPEDITED DATA (Table 4/Q.711),
c)	N–DATA ACKNOWLEDGE,
d)	N–RESET (Table 5/Q.711).
	The primitive “N–DATA” (Table 3/Q.711) exists only as a “request”, i.e. from the SCCP user to the local SCCP and as an “indication” at the remote end of the connection, i.e., from the SCCP to the local SCCP user. N–DATA can occur bidirectionally, i.e., from the calling as well as the called user of the SCCP–connection.
	The parameter “Confirmation request” is used in an N–DATA primitive to indicate the need to confirm the receipt of the N–DATA primitive by the remote SCCP user. The confirmation may be given by the N–DATA ACKNOWLEDGE primitive. Receipt confirmation is provided only on connections which get the Receipt Confirmation facility during setup. The matter is for further study.
	The primitive “N–EXPEDITED DATA” (Table 4/Q.711) may be used by the SCCP user only, if the signalling connection is set up according to a class providing the capability to transfer expedited data (refer to Recommendation Q.714).
TABLE 3/Q.711
Parameters of the primitive N–DATA
	Primitive		
Parameter	N–DATA request	N–DATA indication	
Confirmation request a)	X	X	
User data	X	X	
Connection identification b)	X	X	
X	Parameter present within the primitive.
a)	Parameter conditionally present.
b)	This parameter is for further study.

TABLE 4/Q.711
Parameters of the primitive N–EXPEDITED DATA
	Primitive		
Parameter	N–EXPEDITED DATA request	N–EXPEDITED DATA indication	
User data	 X	X	
Connection identification a)	X	X	
X	Parameter present within the primitive.
a)	This parmeter is for further study.

	The primitive “N–DATA ACKNOWLEDGE” is used when the delivery confirmation service is selected. This primitive is for further study.
	The primitive N–RESET (Table 5/Q.711) can occur in the data transfer state of a connection with a protocol class including flow control. N–RESET overrides all other activities and causes the SCCP to start a re–initialization procedure for sequence numbering. N–RESET appears as a request, an indication, a response and a confirmation. After reception of a N–RESET request and before the sending of a N–RESET confirmation, all NSDUs from SCCP are discarded by th SCCP.
TABLE 5/Q.711
Parameters of the primitive N–RESET
	Primitive				
Parameter	N–RESET 
request	N–RESET indication	N–RESET response	N–RESET confirmation	
Originator		X			
Reason	X	X			
Connection identification a)	X	X	X	X	
X	Parameter present within the primitive.
a)	This parameter is for further study.
	The parameter “Originator” indicates the source of the reset and can be any of the following: the “network service provider” (network originated), the “network service user” (user originated), or “undefined”. The parameter “Reason” indicates “network service provider congestion”, “reason unspecified” or “local SCCP originated” for a network originated reset, and indicates “user synchronization” for a user originated reset. The “Reason” parameter is “undefined” when the “Originator” parameter is “undefined”.
2.1.1.2.4	Release phase
	The primitives for the release phase are N–DISCONNECT request and N–DISCONNECT indication. These primitives are also used for the connection refusal during connection establishment phase. Parameters are included to notify the reason for connection release/refusal and the initiator of the connection release/refusal procedure. User data may be also be included (see Table 6/Q.711).
	The parameter “Originator” indicates the initiator of the connection release or the connection refusal. It may assume the following values:
–	the network service provider,
–	the network service user,
–	undefined.
TABLE 6/Q.711
Parameters of the primitive N–DISCONNECT
	Primitive		
Parameter	N–DISCONNECT request	N–DISCONNECT indication	
Originator		X	
Responding address	X	X	
Reason	X	X	
User data	X	X	
Connection identification a)	X	X	
X	Parameter present within the primitive.
a)	This parameter is for further study.
	The parameter “Reason” gives information about the cause of the connection release or the connection refusal. It may assume any of the following values in accordance with the value of the “Originator”:
These values may be used locally at the originating/initiating node as an implementation option. It is noted that the term “connection rejection” is used in Recommendation X.213 for the “Reason” parameter values.
1)	When the “Originator” parameter indicates the “network service provider”:
–	disconnection – abnormal condition of non–transient nature;
–	disconnection – abnormal condition of transient nature;
–	disconnection – invalid state1);
–	disconnection – release in progress1);
–	connection refusal 2) – destination address unknown (non–transient condition)1);
–	connection refusal 2) – destination inaccessible/non–transient condition1);
–	connection refusal 2) – destination inaccessible/transient condition1);
–	connection refusal 2) – QOS not available/non–transient condition1);
–	connection refusal 2) – QOS not available/transient condition1);
–	connection refusal 2) – reason unspecified/non–transient condition1);
–	connection refusal 2) – reason unspecified/transient condition;1)
–	connection refusal 2) – local error1);
–	connection refusal 2) – invalid state1);
–	connection refusal 2) – no translation1);
–	connection refusal 2) – in restart phase1).

2)	When the “Originator” parameter indicates the “network service user”:
–	disconnection – normal condition;
–	disconnection – abnormal condition;
–	disconnection – end user congestion;
–	disconnection – end user failure;
–	disconnection – SCCP user originated;
–	disconnection – access congestion;
–	disconnection – access failure;
–	disconnection – subsystem congestion;
–	connection refusal 3) – non–transient condition;
–	connection refusal 3) – transient condition;
–	connection refusal 3) – incompatible information in NSDUs;
–	connection refusal 3) – end user originated;
–	connection refusal 3) – end user congestion;
–	connection refusal 3) – end user failure;
–	connection refusal 3) – SCCP user originated;
–	connection refusal 3) – access congestion;
–	connection refusal 3) – access failure;
–	connection refusal 3) – subsystem congestion.
3)	When the “Originator” parameter is “undefined”, then the “Reason” parameter is also “undefined”.
	Note – Addition to, or refinement of, this list of possible values for the parameter “Reason” to convey more specific diagnostic, cause and management information is for further study.
2.1.1.3	Additional SCCP primitive and interface elements
	In addition to those primitives in Recommendation X.213, there is a primitive N–INFORM needed by the SCCP connection–oriented services during data transfer phase. There are also three interface elements used by User Part Type A, e.g. ISDN–UP, as in Figure 1/Q.711.
2.1.1.3.1	Notice service
	The provision of the notice service by use of the “N–INFORM” primitive is for further study.
	The primitive N–INFORM (Table 7/Q.711) is used during data transfer to convey relevant network/user information. The primitive “N–INFORM” will contain the parameters “Reason', “Connection Identification” and “QOS parameter set”.
	The primitive “N–INFORM request” is provided to inform the SCCP of the connection user failure/congestion, or anticipated QOS changes. A further primitive “N–INFORM indication” is provided to indicate actual failures of the SCCP to the SCCP–user functions or anticipated quality of service changes or other indications to the SCCP–user functions.
	The parameter “Reason” contains the network/user information to be conveyed. It may assume the following values:
–	network service provider failure;
–	network service congestion;
–	network service provider QOS change;
–	network service user failure;
–	network service user congestion;
–	network service user QOS change;
–	reason unspecified.
TABLE 7/Q.711
Parameters of the primitive N–INFORM
	Primitive		
Parameter	N–INFORM request	N–INFORM indication	
Reason	X	X	
Connection identification a)	X	X	
QOS parameter set a)	X	X	
X	Parameter present within the primitive.
a)	Parameter is for further study.
2.1.1.3.2	Connection establishment interface elements
	For the User Part Type A in Figure 1/Q.711, two mechanisms are available to set up a signalling connection. For example, the ISDN–User Part may use the mechanism described in § 2.1.1.2.2 or may request the SCCP to initiate a connection and return the information to the ISDN–User Part for transmission within an ISDN–User–Part call setup message, like an Initial Address Message (IAM).
	Three interface elements are defined for the information flow between SCCP and ISDN–User Part:
a)	REQUEST to the SCCP, Type 1 and Type 2;
b)	REPLY from the SCCP.
	The REQUEST Type 1 contains the following parameters:
–	connection identification (for further study);
–	receipt confirmation selection;
–	expedited data selection;
–	quality of service parameter set.
	The REQUEST Type 2 contains the following parameters:
–	protocol class;
–	credit;
–	connection identification (for further study);
–	source local reference;
–	originating signalling point code;
–	reply request;
–	refusal indicator.
	The REPLY contains the following parameters:
–	source local reference;
–	protocol class;
–	credit;
–	connection identification (for further study).
2.1.2	Permanent signalling connections
2.1.2.1	Description
	The setup/release service is controlled by the Administration (e.g. O&M application). The functions for setup and release may be similar to those provided for temporary signalling connections and are for further study. The classes of service are the same.
	Permanently established signalling connections may require additional safeguarding mechanisms within the endpoints (relaypoints) of the connection in order to guarantee their re–establishment in case of a processor outage followed by a recovery.
2.1.2.2	Primitives and parameters
	The primitives and their parameters are listed in Table 8/Q.711. Their content and functionality correspond to the description within § 2.1.1.2.3.
TABLE 8/Q.711
Primitives for the data transfer on permanent connections
Primitives			
Generic Name	Specific Name	Parameters	
N–DATA	Request	Confirmation request	
	Indication	User data	
	Connection identification a)		
N–EXPEDITED DATA	Request	User data	
	Indication	Connection identification a)	
N–DATA ACKNOWLEDGE (for further study)	Request
Indication	Connection identification a)	
N–RESET	Request	Originator	
	Indication	Reason	
	Response	Connection identification a)	
	Confirmation		
a)	Parameter is for further study.
2.2	Connectionless services
	The SCCP provides the SCCP user with the ability to transfer signalling messages via the signalling network without setup of a signalling connection. In addition to the MTP capability, a “Routing” function has to be provided within the SCCP, which maps the called address to the Signalling Point Codes of the MTP Service.
	This mapping function may be provided within each node or might be distributed over the network or could be provided in some special translation centres.
	Under certain conditions of congestion and unavailability of subsystems and/or signalling points, connectionless messages could be discarded instead of being delivered. If the SCCP user wishes to be informed of the non–delivery of messages, the Return Option parameter must be set to “return message on error” in the primitive to the SCCP.

2.2.1	Description
	There are two possibilities to transfer data without a connection setup with regard to the sequence control mechanisms provided by the MTP.
a)	The MTP guarantees (to a high degree of probability) an in–sequence delivery of messages which contain the same Signalling Link Selection (SLS) code. The SCCP user can demand this MTP service by allocating a parameter “Sequence control” into the primitive to the SCCP. The SCCP will put the same SLS code into the primitive to the MTP for all primitives from the SCCP user with the same “Sequence control” parameter.
b)	If the in–sequence delivery is not required, the SCCP can insert SLS codes randomly or with respect to appropriate load sharing within the signalling network.
	The rules to achieve load sharing are not defined in the SCCP Recommendations.
2.2.2	Primitives and parameters of the connectionless service
2.2.2.1	Overview
	Table 9/Q.711 gives an overview of the primitives to the upper layers and the corresponding parameters for the connectionless service.
TABLE 9/Q.711
Primitives and parameters of the connectionless service
Primitives			
Generic Name	Specific Name	Parameters	
N–UNITDATA	Request	Called address	
	Indication	Calling address	
		Sequence control a)	
		Return option a)	
		User data	
N–NOTICE	Indication	Called address	
		Calling address	
		Reason for return	
		User data	
a)	An integration of the parameter Sequence control/Return option into the Quality of Service parameter set is for further study.
2.2.2.2	Parameters
2.2.2.2.1	Address
	The parameters “Called address” and “Calling address” serve to identify the destination and origination respectively, of the connectionless message. These parameters may contain some combination of global titles, subsystem numbers, and signalling point codes.

2.2.2.2.2	Sequence control
	The parameter “Sequence control” indicates to the SCCP whether the user wishes the service “sequence guaranteed” or the service “sequence not guaranteed”. In the case of “sequence guaranteed” service, this parameter is an indication to the SCCP that a given stream of messages with the same called address has to be delivered in sequence by making use of the features of the MTP. In addition, this parameter is also used to distinguish different streams of messages so that the SCCP can allocate SLS codes appropriately to help the MTP in achieving an even distribution of signalling traffic.
2.2.2.2.3	Return option
	The parameter “Return option” is used to determine the handling of messages encountering transport problems.
	“Return option” may assume the following values:
–	discard message on error;
–	return message on error.
2.2.2.2.4	Reason for return
	The parameter “Reason for return” identifies the reason why a message was not able to be delivered to its final destination.
	“Reason for return” may assume the following values:
–	no translation for an address of such nature;
–	no translation for this specific address;
–	subsystem configuration;
–	subsystem failure;
–	unequipped user;
–	network congestion;
–	network failure.
2.2.2.2.5	User data
	The parameter “User data” is information which is to be transferred transparently between SCCP users.
2.2.2.3	Primitives
2.2.2.3.1	UNITDATA
	The “N–UNITDATA request” primitive is the means by which a SCCP user requests the SCCP to transport data to another user.
	The “N–UNITDATA indication” primitive informs a user that data is being delivered to it from the SCCP.
	Table 10/Q.711 indicates the parameters of the primitive N–UNITDATA.
2.2.2.3.2	NOTICE
	The “N–NOTICE indication” primitive is the means by which the SCCP returns to the originating user a message which could not reach the final destination.
	Table 11/Q.711 indicates the parameters of the primitive N–NOTICE.
TABLE 10/Q.711
Parameters of the primitive N–UNITDATA
	Primitive		
Parameter	N–UNITDATA request	N–UNITDATA indication	
Called address	X	X	
Calling address	X	X	
Sequence control a)	X		
Return option	X		
User data	X	X	
a)	The inclusion of this parameter in the N–UNITDATA indication primitive is for further study.

TABLE 11/Q.711
Parameters of the primitive N–NOTICE
	Primitive	
Parameter	N–NOTICE indication	
Called address	X	
Calling address	X	
Reason for return	X	
User data	X	

2.3	SCCP management
2.3.1	Description
	The SCCP provides SCCP management procedures (see Recommendation Q.714, § 5) to maintain network performances by rerouting or throttling traffic in the event of failure or congestion in the network. These SCCP management procedures apply to both the connection–oriented and the connectionless services of the SCCP.
2.3.2	Primitives and parameters of the SCCP management
2.3.2.1	Overview
	Table 12/Q.711 gives an overview of the primitives to the upper layers and the corresponding parameters for the SCCP management.
TABLE 12/Q.711
Primitives and parameters of the SCCP management
Primitives			
Generic Name	Specific Name	Parameters	
R–COORD	Request	Affected subsystem	
	Indication	Subsystem multiplicity indicator	
	Response		
	Confirmation		
N–STATE	Request	Affected subsystem	
	Indication	User status	
		Subsystem multiplicity indicator	
N–PCSTATE	Indication	Affected DPC	
	Signalling Point Status		
2.3.2.2	Parameters
2.3.2.2.1	Address
	See § 2.2.2.2.1.
2.3.2.2.2	Affected subsystem
	The parameter “Affected subsystem” identifies a user which is failed, withdrawn, congested, or allowed. The “Affected subsystem” parameter contains the same type of information as the “Called address” and “Calling address”.
2.3.2.2.3	User status
	The parameter “User status” is used to inform a SCCP user of the status of the affected subsystem.
	“User status” may assume one of the following values:
–	User–in–service (UIS);
–	User–out–of–service (UOS).

2.3.2.2.4	Subsystem multiplicity indicator
	The parameter “Subsystem multiplicity indicator” identifies the number of replications of a subsystem.
2.3.2.2.5	Affected DPC
	The parameter “Affected DPC” identifies a signalling point which is failed, congested, or allowed. The “Affected DPC” parameter contains unique identification of a signalling point.
2.3.2.2.6	Signalling point status
	The parameter “Signalling point status” is used to inform a user of the status of an affected DPC.
	“Signalling point status” may assume the following values:
–	Signalling point inaccessible,
–	Signalling point congested,
–	Signalling point accessible.
2.3.2.3	Primitives
2.3.2.3.1	COORD
	The “N–COORD” primitive (Table 13/Q.711) is used by replicated subsystems to coordinate the withdrawal of one of the subsystems.
	The primitive exists as: a “request” when the originating user is requesting permission to go out of service; an “indication” when the request to go out of service is delivered to the originator's replicate; a “response” when the originator's replicate announced it has sufficient resources to let the originator go out of service; and as a “confirmation” when the originator is informed that it may go out of service.
TABLE 13/Q.711
Parameters of the primitive N–COORD
	Primitive				
Parameter	N–COORD request	N–COORD indication	N–COORD response	N–COORD confirmation	
Affected subsystem	X	X	X	X	
Subsystem multiplicity indicator		X		X	
2.3.2.3.2	STATE
	The “N–STATE request” primitive (Table 14/Q.711) is used to inform the SCCP management about the status of the originating user. The “N–STATE indication” primitive is used to inform an SCCP user accordingly.
TABLE 14/Q.711
Parameters of the primitive N–STATE
	Primitive		
Parameter	N–STATE 
request	N–STATE indication	
Affected subsystem	X	X	
User status	X	X	
Subsystem multiplicity indicator		X	
2.3.2.3.3	PCSTATE
	The “N–PCSTATE primitive” (Table 15/Q.711) is used to inform a user about the status of a signalling point.
TABLE 15/Q.711
Parameters of the primitive N–PCSTATE
	Primitive	
Parameter	N–PCSTATE indication	
Affectedd DPC	X	
Signalling Point Status	X	
3	Services assumed from the MTP
3.1	Description
	This paragraph describes the functional interface offered by the MTP to the upper layer functions, i.e., the SCCP and the User Parts. In order to align the terminology with the OSI–Model, the description uses the terms “primitives” and “parameters”.

3.2	Primitives and parameters
	The primitives and parameters are shown in Table 16/Q.711.
TABLE 16/Q.711
Message transfer part service primitives
Primitives			
Generic Name	Specific Name	Parameters	
MTP–TRANSFER	Request	OPC	
	Indication	DPC	
		SLS	
		SIO	
		User Data	
MTP–PAUSE (Stop)	Indication	Affected DPC	
MTP–RESUME (Start)	Indication	Affected DPC	
MTP–STATUS	Indication	Affected DPC	
		Cause a)	
a)	The cause parameter has, at present, two values:
	ii)	Signalling network congested (level)
		This level value is applicable if national option with congestion priorities and multiple signalling link states without congestion priorities as in Recommendation Q.704 is implemented.
	ii)	Remote user unavailable.
3.2.1	TRANSFER
	The primitive “MTP–TRANSFER” is used between level 4 and level 3 (SMH) to provide the MTP message transfer service.
3.2.2	PAUSE
	The primitive “MTP–PAUSE” indicates to the SCCP total inability of providing the MTP service to the specified destination.
	This primitive corresponds to the destination inaccessible state as defined in Recommendation Q.704.

3.2.3	RESUME
	The primitive “MTP–RESUME” indicates to the SCCP total ability of providing the MTP service to the specified destination.
	This primitive corresponds to the destination accessible state as defined in Recommendation Q.704.
3.2.4	STATUS
	The primitive “MTP–STATUS” indicates to the SCCP partial inability of providing the MTP service to the specified destination, or the unavailability of the remote peer user. The response of the SCCP for the latter case is for further study.
	In the case of national option with congestion priorities and multiple signalling link congestion states without priorities as in Recommendation Q.704 is implemented, this “MTP–STATUS” primitive is also used to indicate a change of congestion level.
	This primitive corresponds to the destination congested state as defined in Recommendation Q.704.
4	Functions provided by the SCCP
	This section is an overview of the functional blocks within the SCCP.
4.1	Connection–oriented functions
4.1.1	Functions for temporary signalling connections
4.1.1.1	Connection establishment functions
	The connection establishment service primitives defined in § 2 are used to set up a signalling connection.
	The main functions of the connection establishment phase are listed below:
–	Setup of a signalling connection;
–	Establish the optimum size of NPDUs (Network Protocol Data Unit);
–	Map network address onto signalling relations;
–	Select functions operational during data transfer phase (for instance, layer service selection);
–	Provide means to distinguish network connections;
–	Transport user data (within the request).
4.1.1.2	Data transfer phase function
	The data transfer phase functions provide means for a two–way simultaneous transport of messages between the two endpoints of the signalling connection.
	The main functions of the data transfer phase as listed below are used or not used in accordance with the result of the selection performed in the connection establishment phase.
–	Segmenting/reassembling,
–	Flow control,
–	Connection identification,
–	NSDU delimiting (M–Bit),
–	Expedited data,
–	Missequence detection,
–	Reset,
–	Receipt confirmation4),
–	Others.

4.1.1.3	Release phase functions
	These functions provide disconnection of the signalling connection, regardless of the current phase of the connection. The release may be performed by an upper layer stimulus or by maintenance of the SCCP itself. The release can start at each end of the connection (symmetrical procedure).
	The main function of the release phase is the disconnection.
4.1.2	Functions for permanent signalling connections
4.1.2.1	Connection establishment phase and connection release phase functions
	The setup and release for permanent signalling connections are for further study. The stimuli for setup and release of permanent connections are originated from the Administration function.
4.1.2.2	Data transfer phase functions
	The functions for the data transfer on permanent signalling connections correspond to that for temporary connections. Differences may exist regarding the quality of service. This matter is for further study.
4.2	Connectionless service functions
	The functions of the connectionless service are listed below:
–	mapping the network address to signalling relations,
–	sequence service classification.
4.3	Management functions (for further study)
	The SCCP provides functions which manage the status of the SCCP subsystems. These functions allow other nodes in the network to be informed of the change in status of SCCP subsystems at a node, and to modify SCCP translation data if appropriate. Subsystem congestion management is for further study.
	Functions are also provided to allow a coordinated change of status of replicated SCCP subsystems. At present, this allows a replicated subsystem to be withdrawn from service.
	When a subsystem is out of service, SCCP test functions are activated at nodes receiving unavailability information. At periodic intervals the status of the unavailable subsystem is checked by a SCCP management procedure.
	Broadcast functions within SCCP management broadcast subsystem status changes to nodes within the network which have an immediate need to be informed of a particular signalling point/subsystem status change.
	Notification functions to local subsystems within the node (local broadcast) are also provided.
4.4	Routing and translation functions (for further study)
	The SCCP routing provides a powerful address translation function, which is asked for connectionless and connection–oriented service. Detailed description of the SCCP routing function can be found in Recommendation Q.714, §§ 2.2 and 2.3.
	The basic translation function performed by the SCCP is to transfer the SCCP address parameter from a global title to a point code and a subsystem number. Other translation results are also possible. The global title form of the address could typically be dialed digits (e.g. a Freephone (800) number). Several standardized CCITT numbering plans may be supported by SCCP; details are given in Recommendation Q.713, § 3.4.
	The address translation capabilities of the SCCP in relation to handling OSI Network Service Access Points (NSAP) are for further study.

ANNEX A
(to Recommendation Q.711)
OSI network layer conformance
	The following information should be taken into account when reading Recommendation Q.711 in relation to the provision of an OSI network layer service.
	All references to connectionless classes 0 and 1 are not included in Recommendation X.200.
§ 2.1.1
	The Connection identification parameters in the following primitives are implicit in Recommendation X.213:
N–CONNECT
N–DATA
N–EXPEDITED DATA
N–DATA ACKNOWLEDGE
N–DISCONNECT
N–RESET
	The N–INFORM primitive does not exist within Recommendation X.213.
	The connection establishment interface elements described in § 2.1.1.3.2 is not required to support an OSI network layer service.
§ 2.1.2
	Permanent connection services are not defined in Recommendation X.200 and are not required to support an OSI network layer service. The service is offered by the SCCP for specific No. 7 applications.
§ 2.2
	Connectionless network service is still under study in Study Group VII and is not defined in Recommendation X.213.
§ 2.3
	This section on SCCP management is not defined in Recommendation X.213 and none of the primitives exist in OSI.
APPENDIX
(to Recommendation Q.711)
Unresolved issues in SCCP Recommendations
	This appendix lists the topics in SCCP on which study is continuing in the next study period. It is not an exhaustive list, but does indicate where the Recommendations might change. In these areas, RPOAs may need to supplement the Recommendations, but in such a way as not to conflict with ongoing work; implementors should consider likely future developments and, where possible, design to accommodate these.
	The topics under study are listed below; the references are to the Blue Book.
1)	Inter–nodal communication model with SCCP connectionless service (§ 1.3.3, Rec. Q.711);
2)	Delivery confirmation service (N–DATA ACKNOWLEDGE primitive) (Table 1/Q.711);
3)	Transitions caused by N–DATA ACK primitive (Figure 7/Q.711);

4)	Facilities causing differences in the called and responding addresses in N–CONNECT request and response (§ 2.1.1.2.2, Rec. Q.711);
5)	The need for Receipt Confirmation Service in SCCP (§§ 2.1.1.2.2 and 4.1.1.2, Rec. Q.711);
6)	Connection identification parameter inclusion in Request types 1 and 2, and reply primitives between SCCP and ISUP (§ 2.1.1.3.2, Rec. Q.711);
7)	Connection identification parameter inclusion in N–CONNECT, N–DATA, N–EXPEDITED DATA, N–RESET, and N–DISCONNECT primitives (Tables 2/Q.711, 3/Q.711, 4/Q.711, 5/Q.711, 6/Q.711, 7/Q.711, 8/Q.711);
8)	The list of release reason parameter values (§ 2.1.1.2, Rec. Q.711);
9)	QOS parameter set inclusion in N–INFORM (Table 7/Q.711);
10)	Setup and release functions for permanent signalling connections (§ 2.1.2.1, Rec. Q.711);
11)	Integrating sequence control and return option parameters in the QOS set (Table 9/Q.711);
12)	Sequence control parameter inclusion in the N–UNITDATA indication primitive (Table 10/Q.711);
13)	SCCP response to MTP–STATUS (§ 3.2.4, Rec. Q.711);
14)	Difference in QOS between permanent and temporary signalling connections (§ 4.1.2.2, Rec. Q.711);
15)	SCCP management procedures for subsystem congestion (§ 4.3, Rec. Q.711; §§ 3.11, 3.12, 3.15, Rec. Q.713; §§ 5.1, 5.3, Rec. Q.714);
16)	SCCP capabilities in OSI NSAP address translation (§ 4.4, Rec. Q.711);
17)	Possible need for diagnostic parameter (§ 2.6, Rec. Q.712);
18)	Constraints on order of optional parameter transmission (§ 1.8, Rec. Q.713);
19)	Destination local reference coded as all ones (§ 3.2, Rec. Q.713);
20)	Source local reference coded as all ones (§ 3.3, Rec. Q.713);
21)	Alignment with X.96 call progress information (§§ 3.11, 3.15, Rec. Q.713);
22)	Inclusion of routing failure causes as for return cause in Recommendation Q.713, § 3.12 (§ 3.15, Rec. Q.713);
23)	Data parameter maximum length for Unitdata and Unitdata Service messages (§§ 4.10, 4.11, Rec. Q.713; §§ 1.1.2, 4, Rec. Q.714);
24)	Need for Released message cause value 1110 “not obtainable” (Annex A, Rec. Q.713);
25)	Need for Reset Request message cause value 1011 “not obtainable” (Annex A, Rec. Q.713);
26)	Notification regarding unrecognized messages/parameters (§ 1.14, Rec. Q.714);
27)	Classification of SCCP routing failure causes (§ 2.4, Rec. Q.714);
28)	Management procedures for non–dominant mode nodes/subsystems with more than one backup (§ 5.1, Rec. Q.714);
29)	Receipt from a local originating subsystem of a message for a prohibited subsystem (§ 5.3.2.1, Rec. Q.714);
30)	Possible introduction of a subsystem out of service denial message (§ 5.3.5.3, Rec. Q.711);
31)	Mathematical analysis of SCCP performance;
32)	Recommendation Q.716 parameter valus (§ 3, Rec. Q.716).