Recommendation Q.761
FUNCTIONAL DESCRIPTION OF THE ISDN USER PART
OF SIGNALLING SYSTEM No. 7
1	General
	The ISDN User Part is the Signalling System No. 7 protocol which provides the signalling functions required to support basic bearer services and supplementary services for voice and non–voice applications in an integrated services digital network.
	The ISDN User Part is also suited for application in dedicated telephone and circuit switched data networks and in analogue and mixed analogue/digital networks. In particular the ISDN User Part meets the requirements defined by CCITT for worldwide international semi–automatic and automatic telephone and circuit switched data traffic.
	The ISDN User Part is furthermore suitable for national applications. Most signalling procedures, information elements and message types specified for international use are also required in typical national applications. Moreover, coding space has been reserved in order to allow national administrations and recognized private operating agencies to introduce network specific signalling messages and elements of information within the internationally standardized protocol structure.
	The ISDN User Part makes use of the services provided by the Message Transfer Part (MTP) and in some cases by the Signalling Connection Control Part (SCCP) for the transfer of information between ISDN User Parts.
	The ISDN User Part protocol which supports the basic bearer service is described in Recommendations Q.761 to Q.764 and Q.766. A general description of ISDN User Part signals and messages is provided in Recommendation Q.762. Message formats and message field codings are defined in Recommendation Q.763, while the signalling procedures are described in Recommendation Q.764. Recommendation Q.766 deals with ISDN User Part performance objectives.
	ISDN User Part protocol elements which support supplementary services are described in Recommendation Q.730.
	Note – The message set, message formats and procedures specified in this version of the ISDN User Part protocol are not in complete alignment with those of the 1984 version (Red Book). The two versions of the protocol are therefore not compatible in all aspects.
2	Services supported by the ISDN User Part
	The ISDN User Part protocol supports the basic bearer service, i.e. the establishment, supervision and release of 64 kbit/s circuit switched network connections between subscriber line exchange terminations.
	In addition to the basic bearer service the ISDN User Part also supports the following supplementary services:
–	calling line identification,
–	call forwarding,
–	closed user groups,
–	directing dialling in, and
–	user–to–user signalling.

3	Services assumed from the Message Transfer Part (MTP)
3.1	General
	This section describes the functional interface presented by the Message Transfer Part to the ISDN User Part. In accordance with the description techniques defined by the Open System Interconnection (OSI) model, information is transferred to and from the MTP in the form of Parameters carried by Primitives.
	The general syntax of a primitive is as follows:

X	 Generic name	 Specific name	 Parameter	

where
X designates the function providing the service (the MTP, in this case),
the Generic name describes an action by X,
the Specific name indicates the purpose of the primitive, i.e. whether it conveys a request for service, an indication that service related information has been received, a response to a service request or a confirmation that the requested service has been performed, and
the Parameters contain the elements of supporting information transferred by the primitive.
3.2	Description of primitives
	The following paragraphs describe the primitives used across the ISDN User Part–Message Transfer Part functional interface. The primitives together with the parameters carried by each primitive are also shown in Table 1/Q.761.
3.2.1	Transfer
	The MTP–TRANSFER primitive is used either by the ISDN User Part to access the Signalling Message Handling function of the Message Transfer Part or by the latter to deliver signalling message information to the ISDN User Part.
3.2.2	Pause
	The MTP–PAUSE primitive is sent by the Message Transfer Part to indicate its inability to transfer messages to the destination specified as a parameter.
3.2.3	Resume
	The MTP–RESUME primitive is sent by the Message Transfer Part to indicate its ability to resume unrestricted transfer of messages to the destination specified as a parameter.
3.2.4	Status
	The MTP–STATUS primitive is sent by the Message Transfer Part to indicate that the signalling route to a specific destination is congested or the ISDN User Part at the destination is unavailable. The affected destination and the congestion indication are carried as parameters (see Table 1/Q.761) in the primitive.
TABLE 1/Q.761
Message transfer part service primitives
Primitives			
 Generic name	 Specific name	 Parameters	
 MTP–TRANSFER	Request	OCP	
	indication	DPC	
		SLS	
		SIO	
		Signalling info.	
 MTP–PAUSE	 Indication	 Affected DPC	
 MTP–RESUME	 Indication	 Affected DPC	
 MTP–STATUT	 Indication	 Affected DPC	
		Cause (see Note)	
 OPC	Originating point code
DPC	Destination point code
SLS	Signaling link selection code
SIO	Service information octet
Note – The cause parameter can assume two values:
–	signalling network congested (level), where level is included only if natioal options with congestion priorities and multiple signalling states without congestion priorities (see Recommendation Q.704).
–	remote user unavailable.
4	End–to–end signalling
4.1	General
	End–to–end signalling is defined as the capability to transfer signalling information of end points significance directly between signalling end points in order to provide a requesting user with a basic or supplementary service.
	End–to–end signalling is used typically between call originating and terminating local exchanges, to request or to respond to requests for additional call related information, to invoke a supplementary service or to transfer user–to–user information transparently through the network.
	End–to–end signalling procedures are described in Recommendation Q.764, § 3.
	The following two methods of end–to–end signalling are supported:
4.2	SCCP method of end–to–end signalling
	Connection–oriented or connectionless transfer of end–to–end signalling information can be accomplished by using the service provided the Signalling Connection Control Part (SCCP) of Signalling System No. 7. The relevant procedures are described in Recommendation Q.764, § 3.4.
4.3	Pass–along method of end–to–end signalling
	The pass–along method of end–to–end signalling provides transfer of signalling information without requiring the services of the SCCP.
	This method may be used between two exchanges when the information to be transferred relates to an existing call for which a physical connection between the same two exchanges has been established. The information transfer in this case occurs over the same signalling path as that used to set up the call and establish the physical connection.
	The relevant procedures are described in Recommendation Q.764, § 3.3.
5	Future enhancements
	Requirements for additional protocol capabilities, such as the ability to support new supplementary services, will result from time to time in the need to add to or modify existing protocol elements and thus to create a new protocol version.
	In order to ensure adequate service continuity, the insertion of a new protocol version into one part of a network should be transparent to the remainder of the network. Compatible interworking between protocol versions is optimized by adhering to the following guidelines when specifying a new version:
1)	Existing protocol elements, i.e. procedures, messages, parameters and codes, should not be changed unless a protocol error needs to be corrected or it becomes necessary to change the operation of the service that is being supported by the protocol.
2)	The semantics of a message, a parameter or of a field within a parameter should not be changed.
3)	Established rules for the formatting and encoding messages should not be modified.
4)	The addition of parameters to the mandatory part of an existing message should not be allowed. If needed, a new message should be defined containing the desired set of existing and new mandatory parameters.
5)	A parameter may be added to an existing message as long as it is allocated to the optional part of the message.
6)	The addition of new octets to an existing mandatory fixed length parameter should be avoided. If needed, a new optional parameter should be defined containing the desired set of existing and new information fields.
7)	The sequence of fields in an existing variable length parameter should remain unchanged. New fields may be added at the end of the existing sequence of parameter fields. If a change in the sequence of parameter fields is required, a new parameter should be defined.
8)	The all zeros code point should be used exclusively to indicate an unallocated (spare) or insignificant value of a parameter field. This avoids an all zeros code, sent by one protocol version as a spare value, to be interpreted as a significant value in another version.