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. Fascicle VI.8 - Rec. Q.761 PAGE1 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 PAGE4 Fascicle VI.8 - Rec. Q.761 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, S 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, S 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, S 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 Fascicle VI.8 - Rec. Q.761 PAGE1 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. PAGE4 Fascicle VI.8 - Rec. Q.761