WPCL 2BJ|x H   X  6p&6p&   H   c4 P  Fascicle VI.8 - Rec. Q.761 PAGE1  c4 P    HH  c4 P PAGE4  c4 P  Fascicle VI.8 - Rec. Q.761  HH Hp P X`h!(# X    c4 P Recommendation Q.761 HP X`h!(#8< c4 P FUNCTIONAL DESCRIPTION OF THE ISDN USER PART 8EOF SIGNALLING SYSTEM No. 7 Hp P X`h!(# c4 P 1X General  H Ё 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.  H  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.  H  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.  H  The ISDN User Part protocol which supports the basic bearer service is described in RecommendationsQ.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 RecommendationQ.763, while the signalling procedures are described in Recommendation Q.764. Recommendation Q.766 deals with ISDN User Part performance objectives.  H  ISDN User Part protocol elements which support supplementary services are described in RecommendationQ.730.  H  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. HP X`h!(#X X  H 2  c4 P Services supported by the ISDN User Part  H Hp P X`h!(#Ё c4 P   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.  H  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. HH Ђ  3pServices assumed from the Message Transfer Part (MTP) 3.1h  General  H  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: H8( ҇YX S Generic name R Specific name T Parameter  HH Ё where  H   X designates the function providing the service (the MTP, in this case),   the Generic name describes an action by X,  H   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  H   the Parameters contain the elements of supporting information transferred by the primitive.  HH HP X`h!(#X X  H3.2  Description of c4 P  primitives  H Hp P X`h!(# c4 P  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 Table1/Q.761.  H3.2.1 Transfer  H  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.  H3.2.2 Pause  H  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.  H3.2.3 Resume  H  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.  H3.2.4 Status  H  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. S c4 P TABLE 1/Q.761 E Message transfer part service primitives  c4 P Hx҇HP X c4 P Primitives Hp P X`h!(#   p P X`h!(# c4 P ш   c4 P H x҇p P .i c4 P  Generic name .h Specific name .j Parameters    c4 P ш   c4 P H x҇ c4 P  MTP-TRANSFER Request OCP    c4 P ш   c4 P H x҇ c4 P  indication DPC    c4 P ш   c4 P H x҇ c4 P  SLS    c4 P ш   c4 P H x҇ c4 P  SIO    c4 P ш   c4 P H x҇ c4 P  Signalling info.    c4 P ш   c4 P H x҇ c4 P  MTP-PAUSE Indication Affected DPC    c4 P ш   c4 P H x҇ c4 P  MTP-RESUME Indication Affected DPC    c4 P ш   c4 P H x҇ c4 P  MTP-STATUT Indication Affected DPC    c4 P ш   c4 P H x҇ c4 P  Cause (see Note)    c4 P ш ( (p P X`h!(# c4 P  OPCpOriginating point code DPCpDestination point code SLSpSignaling link selection code SIOpService 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.  HH HP X`h!(#X X  H  c4 P 4  c4 P End-to-end signalling Hp P X`h!(#Ё c4 P 4.1h  General  H  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.  H  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.2h  SCCP method of end-to-end signalling  H  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.3h  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.  H  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. 5X Future enhancements  H Ё 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.  H  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:  H   1)pExisting 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.  H   2)pThe semantics of a message, a parameter or of a field within a parameter should not be changed.  H   3)pEstablished rules for the formatting and encoding messages should not be modified.  H   4)pThe 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.  H   5)pA parameter may be added to an existing message as long as it is allocated to the optional part of the message.  H   6)pThe 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.  H   7)pThe 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.  H   8)pThe 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.