Professional Documents
Culture Documents
T Rec Q.711 200103 I!!pdf e PDF
T Rec Q.711 200103 I!!pdf e PDF
ITU-T Q.711
TELECOMMUNICATION (03/2001)
STANDARDIZATION SECTOR
OF ITU
Summary
The Q.71X-series Recommendations defines the services of the SCCP. The SCCP is part of SS No. 7
and provides, above the MTP network or networks, connectionless, connection-oriented, routing and
management services.
Source
ITU-T Recommendation Q.711 was revised by ITU-T Study Group 11 (2001-2004) and approved
under the WTSA Resolution 1 procedure on 1 March 2001.
NOTE
In this Recommendation, the expression "Administration" is used for conciseness to indicate both a
telecommunication administration and a recognized operating agency.
ITU 2001
All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from ITU.
(Note)
SCCP
MTP
T1157170-93
NOTE – Interface using the signals as defined in 6.1.1.3.3, i.e. for the connection-oriented
network service.
The ISDN-UP that provides end-to-end signalling as defined in ITU-T Q.730 is
a type A user part.
Figure 1/Q.711 – Functional diagram for the SCCP in Signalling System No. 7
2 References
The following ITU-T Recommendations and other references contain provisions which, through
reference in this text, constitute provisions of this Recommendation. At the time of publication, the
editions indicated were valid. All Recommendations and other references are subject to revision;
users of this Recommendation are therefore encouraged to investigate the possibility of applying the
most recent edition of the Recommendations and other references listed below. A list of the currently
valid ITU-T Recommendations is regularly published.
The references contained in 2.1 and 2.2 contain the reference list for ITU-T Q.711, ITU-T Q.712,
ITU-T Q.713 and ITU-T Q.714.
3 Definitions
Definitions of SCCP terms are provided in the glossary of CCITT Blue Book, Fascicle VI.7.
In addition to the definitions referenced, the following definitions apply:
3.1 MTP-SAP instance: A logical point in the MTP network at which an MTP user can access
the services provided by the MTP-3 or the MTP-3b and the MTP can deliver its services to the MTP
user.
3.2 SCCP-SAP instance: A logical point in the SCCP network at which an SCCP user can
access the services provided by the SCCP and the SCCP can deliver its services to the SCCP user.
5 General characteristics
MTP
service
definition
T1157180-93
5.2 Primitives
Primitives define the information flow associated with the services requested of the SCCP and of the
MTP (see Figure 3).
Upper
layers
N-Service primitives
SCCP-SAP
Services of the SCCP
Signalling
Service access
connection control
points (SAP)
part
MTP-SAP
MTP-Service primitives Services of the MTP
Service primitives
Message
transfer part
T1157190-93
This diagram shows the points at which service primitives are invoked. It is not intended to constrain
the architecture. For the architectural considerations, some information is provided in ITU-T Q.1400.
Node A Node B
User of the User of the
network network
service service
Queue B to A
Queue A to B
T1157200-93
Figure 4/Q.711 – Model for the internode communication with the SCCP
(connection-oriented services)
Node X Node Y
User of the User of the
network network
service service
SCCP-SAP A SCCP-SAP B
Service provider
T1178310-96
NPCI NSDU
Message
T1157210-93
NPCI NSDU
Message 1 Message 2
T1157220-93
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 ITU-T Q.714).
6.1.1.2 Network service primitives and parameters applicable to the X.213-like connection-
oriented boundary
6.1.1.2.1 Overview
Table 1 gives an overview of the primitives to the upper layers and the corresponding parameters for
the (temporary) connection-oriented network service. Figure 8 shows an overview state transition
diagram for the sequence of primitives at a connection endpoint. Refer to the ITU-T X.213 network
service definition for open systems interconnection for ITU-T application.
N-CONNECT N-CONNECT
Outgoing request indication Incoming
connection REQUEST type 1 a), b) REQUEST type 2 a), b) connection
pending pending
N-DISCONNECT
request, indication
a), b) N-CONNECT
REPLY N-CONNECT N-CONNECT
response
confirm indication b)
Data transfer
N-RESET
N-RESET indication
request
N-DATA
N-RESET N-EXPEDITED DATA N-RESET
User requested response Provider initiated
reset pending confirm N-INFORM a)
reset pending
(request, indication)
T1178320-96
N-DATA N-DATA
N-EXPEDITED DATA N-EXPEDITED DATA
request, indication request, indication
A more detailed description for the primitives and their parameters is given in the following clauses.
The parameters "called address/calling address" convey addresses identifying the destination/source
of a communication. There are three types of address information elements:
– global title;
– subsystem number;
– signalling point code (together with the MTP-SAP instance).
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" identifies the SCCP user to which the connection has been
established or refused.
The "responding address" parameter in the N-CONNECT primitive conveys the address of the SCCP
service access point to which the signalling connection has been established. Under certain
circumstances (e.g. a general global title identifying replicated subsystems), the value of this
parameter may be different from the "called address" in the corresponding N-CONNECT request.
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 primitive "N-DATA" (Table 3) 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 primitive "N-EXPEDITED DATA" may only be used by the SCCP user in case of protocol
class 3 connections.
The primitive N-RESET (Table 5) 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 confirm. After reception of an N-RESET request and before the sending of an
N-RESET confirm, all NSDUs from the remote SCCP and the local SCCP user are discarded by the
local SCCP.
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 originated1" 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".
____________________
1 These values may be used locally at the originating/initiating node as an implementation option.
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.
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":
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 refusal2 – destination address unknown (non-transient condition);
– connection refusal2 – destination inaccessible/non-transient condition;
– connection refusal2 – destination inaccessible/transient condition;
– connection refusal2 – QOS not available/non-transient condition;
– connection refusal2 – QOS not available/transient condition;
– connection refusal2 – reason unspecified/non-transient condition;
– connection refusal2 – reason unspecified/transient condition;
– connection refusal2 – local error1;
– connection refusal2 – invalid state1;
– connection refusal2 – no translation1;
– connection refusal2 – in restart phase1;
– connection refusal2 – hop counter violation.
____________________
2 It is noted that the term "connection rejection" is used in ITU-T X.213 for the "reason" parameter values.
6.1.1.3 Network service primitives, interface elements and parameters applicable to the
ISUP-embedded connection-oriented boundary
6.1.1.3.1 Overview
Table 7 gives an overview of the primitives to the SCCP user layer and the corresponding
parameters for the (temporary) "ISUP-embedded" connection-oriented network service. The state
transition diagram for the sequences of the primitives at a connection endpoint is left for further
study.
The primitive "N-INFORM request" is provided to inform the local 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 local 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.
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 (O);
– expedited data selection (U);
– quality of service parameter set (U).
The REQUEST type 2 contains the following parameters:
– quality of service parameter set (M);
– connection identification (O);
– source local reference (M);
– originating signalling point code (M);
– reply request (U);
– refusal indicator (U).
The REPLY contains the following parameters:
– source local reference (M);
– quality of service parameter set (M);
– connection identification (O).
6.2.1 Description
The connectionless SCCP offers two services:
Class 0: The basic connectionless class without guaranteed in-sequence delivery of SCCP-SDUs.
The SCCP user can invoke this service by means of the parameter "sequence control" in
the N-UNITDATA request primitive being absent; and
6.2.2.2 Parameters
6.2.2.2.1 Address
The parameters "called address" and "calling address" serve to identify the destination and
origination respectively, of the SCCP-SDU to be conveyed in connectionless messages. It should be
noted that the called and calling addresses may be different at the origination and destination. These
parameters may contain some combination of global title, subsystem number and signalling point
code.
____________________
3 By the MTP network or by concatenated MTP networks concerned (for further information, see
ITU-T Q.706).
6.2.2.3 Primitives
6.2.2.3.1 UNITDATA
The "N-UNITDATA request" primitive is the means by which an SCCP user requests the SCCP to
transfer SCCP-SDUs to a peer SCCP user.
The "N-UNITDATA indication" primitive informs a user that a SCCP-SDU is being delivered to it
from the peer SCCP user.
Table 12 indicates the parameters of the primitive N-UNITDATA.
6.2.2.3.2 NOTICE
The "N-NOTICE indication" primitive is the means by which the SCCP returns to the originating
user a SCCP-SDU which could not reach the final destination.
Table 13 indicates the parameters of the primitive N-NOTICE.
N-UNITDATA request/indication
N-NOTICE indication
Idle
T1178330-96
6.3.2.2 Parameters
6.3.2.2.1 Affected subsystem
The parameter "affected subsystem" identifies a user which is failed, withdrawn, or allowed. The
"affected subsystem" parameter contains the same type of information as the "called address" and
"calling address", except the global title portion.
6.3.2.3 Primitives
6.3.2.3.1 COORD
The "N-COORD" primitive (Table 15) 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 "confirm" when the originator is informed that it may go
out-of-service.
6.3.2.3.2 STATE
The "N-STATE request" primitive (Table 16) 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.
6.3.2.3.3 PCSTATE
The "N-PCSTATE primitive" (Table 17) is used to inform a user about the status of a signalling
point or a remote SCCP.
7.1 MTP-SAP
The services provided by the MTP are offered at two different MTP-SAPs:
a) An MTP-SAP that supports a maximum MTP-SDU size of 272 octets, including the MTP
routing label (see 2.3.8/Q.703).
b) An MTP-SAP that supports a maximum MTP-SDU size of 4095 octets, including the MTP
routing label (see 9.1/Q.2210).
With the exception of the maximum supported SDU size, these two SAPs offer equivalent services.
7.2.1 TRANSFER
The primitive "MTP-TRANSFER" is used between SCCP and MTP to provide the MTP message
transfer service.
7.2.2 PAUSE
The primitive "MTP-PAUSE" indicates to the SCCP the total inability of providing the MTP service
to the specified destination4.
NOTE – The signalling point is inaccessible via the MTP. The MTP will determine when the signalling point
is again accessible and send MTP-RESUME indication. The user should wait for such an indication and,
meanwhile, is not allowed to send messages to that signalling point. If the remote peer user is thought to be
unavailable, that condition may be maintained or cancelled at the local user's discretion.
____________________
4 If MTP provides services according to ITU-T Q.704, see 7.2.6/Q.701, items iii), iv) and v); otherwise, this
reference to ITU-T Q.701 does not apply.
7.2.4 STATUS
The primitive "MTP-STATUS" indicates to the SCCP the partial inability of providing the MTP
service to the specified destination. The primitive is also used to indicate to a user that a remote
corresponding user is unavailable and the cause for unavailability (see 11.2.7/Q.704).
In the case of national option with congestion priorities and multiple signalling link congestion states
without priorities, as in ITU-T Q.704, are implemented, this "MTP-STATUS" primitive is also used
to indicate a change of congestion level.
This primitive corresponds to the destination congested/user part unavailable state as defined in
ITU-T Q.704.
NOTE – In the case of remote user unavailability, the user is responsible for determining the availability of
this peer user. The user is cautioned not to send normal traffic to the peer user because, while such peer user is
unavailable, no message will be delivered but each will result in a repeated MTP-STATUS indication. The
MTP will not send any further indications about the unavailability or availability of this peer user unless the
local user continues to send messages to the peer user.
MTP-RESUME indication
Failure
(Note 2)
MTP-PAUSE indication
Failure
(Note 2)
available
2
MTP-TRANSFER request
MTP-TRANSFER indication
MTP-STATUS indication (for
MTP signalling relation a remote unavailable SCCP
unavailable or to indicate MTP congestion)
3 (Note 3)
T1178340-96
MTP-TRANSFER indication (Note 1)
MTP-STATUS indication (for
a remote unavailable SCCP or to
indicate MTP congestion)
NOTE 1 – MTP-TRANSFER indication in state 3 is a result of the availability of the signalling relation towards the local
MTP, but the unavailability of the signalling relation towards the remote MTP.
NOTE 2 – These transitions are implicity triggered by the MTP restart procedure. The end of the MTP restart is communicated
to the local MTP users by means of implementation-dependent indications showing each signalling point's accessibility or
inaccessibility.
NOTE 3 – The MTP itself does not keep track of the status of the remote MTP users, so the SCCP is responsible for
detecting the availability of its remote peer SCCP.
MTP-RESUME indication
(Note 2)
Failure
Failure
MTP-PAUSE indication
(Note 2)
MTP-RESUME indication
available
2
T1178360-96
MTP-TRANSFER request
MTP-TRANSFER indication
MTP-STATUS indication (for
MTP signalling relation a remote unavailable SCCP or to
unavailable indicate MTP congestion + level)
3 (Note 3)
NOTE 1 – MTP-TRANSFER indication in state 3 is a result of the availability of the signalling relation towards the local
MTP, but the unavailability of the signalling relation towards the remote MTP.
NOTE 2 – These transitions are implicitly triggered by the MTP restart procedure. The end of the MTP restart is communicated
to the local MTP users by means of implementation-dependent indications showing each signalling point's accessibility
or inaccessibility.
NOTE 3 – The MTP itself does not keep track of the status of the remote MTP users, so the SCCP is responsible for
detecting the availability of its remote peer SCCP.
MTP-RESUME indication
(Note 2)
Failure
MTP-PAUSE indication
Failure
MTP-STATUS indication,
(Note 2)
MTP-PAUSE indication
MTP-RESUME indication
MTP-TRANSFER request
MTP-TRANSFER indication
MTP-STATUS indication
(unavailable remote SCCP) (Note 3)
MTP signalling relation MTP signalling relation
unavailable MTP-PAUSE indication congested
3 4
T1178350-96
NOTE 1 – MTP-TRANSFER indication in state 3 is a result of the availability of the signalling relation towards the local MTP,
but the unavailability of the signalling relation towards the remote MTP.
NOTE 2 – These transitions are implicitly triggered by the MTP restart procedure. The end of the MTP restart is communicated
to the local MTP users by means of implementation-dependent indications showing each signalling point's accessibility or
inaccessibility.
NOTE 3 – The MTP itself does not keep track of the status of the remote MTP users, then, the SCCP is responsible for
detecting the availability of its remote peer SCCP.
NOTE 4 – Further study is required to take into account the MTP level congestion procedure into the SCCP congestion
procedures.
Series J Cable networks and transmission of television, sound programme and other multimedia signals
Series K Protection against interference
Series L Construction, installation and protection of cables and other elements of outside plant
Series M TMN and network maintenance: international transmission systems, telephone circuits,
telegraphy, facsimile and leased circuits
Series N Maintenance: international sound programme and television transmission circuits
Series O Specifications of measuring equipment
Series P Telephone transmission quality, telephone installations, local line networks
Geneva, 2001