home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Standards
/
CD2.mdf
/
ccitt
/
1992
/
q
/
q711.asc
< prev
next >
Wrap
Text File
|
1991-12-31
|
71KB
|
2,270 lines
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 N 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
Fascicle VI.7 - Rec. Q.711 PAGE1
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
PAGE6 Fascicle VI.7 - Rec. Q.711
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
Fascicle VI.7 - Rec. Q.711 PAGE1
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
PAGE6 Fascicle VI.7 - Rec. Q.711
Confirmation request
Indication User data
Connection identification a)
N-EXPEDITED DATA Request User data
Indication Connection identification a)
N-DATA ACKNOWLEDGE Request Connection identification a)
(for further study)
Indication
N-DISCONNECT Request Originator
Indication Reason
User data
Responding address
Fascicle VI.7 - Rec. Q.711 PAGE1
Connection identification a)
N-RESET Request Originator
Indication Reason
Response Connection identification a)
Confirmation
a) In Recommendation X.213, S 5.3, this parameter is implicit.
PAGE6 Fascicle VI.7 - Rec. Q.711
Figure 7/Q.711 - T1113281-88
Fascicle VI.7 - Rec. Q.711 PAGE1
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 N-CONNECT N-CONNECT N-CONNECT
request indication response confirmation
Called address X X d)
Calling address X d) X
Responding address X X
Receipt confirmation X X X X
election a)
Expedited data X X
selection
PAGE6 Fascicle VI.7 - Rec. Q.711
X X
Quality of service X X X X
parameter set
User data b) X X X X
Connection X X X X
identification c)
XParameter 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.
Fascicle VI.7 - Rec. Q.711 PAGE1
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.7 s 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.
PAGE6 Fascicle VI.7 - Rec. Q.711
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 N-EXPEDITED DATA
request indication
User data X X
Connection identification a) X X
X Parameter present within the primitive.
a) This parmeter is for further study.
Fascicle VI.7 - Rec. Q.711 PAGE1
The primitive "N-DATA ACKNOWLEDGE" is used when the delivery confirmation
service is selected. This primitive is for further study.
The primitive (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 N-RESET N-RESET N-RESET
request indication response confirmation
Originator X
Reason X X
Connection X X X X
identification a)
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 f 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
PAGE6 Fascicle VI.7 - Rec. Q.711
Parameter N-DISCONNECT N-DISCONNECT
request 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);
1) These values may be used locally at the originating/initiating node as an
implementation option.
2) It is noted that the term "connection rejection" is used in Recommendation X.213 for
the "Reason" parameter values.
Fascicle VI.7 - Rec. Q.711 PAGE1
- connection refusal 2) - invalid state1);
- connection refusal 2) - no translation1);
- connection refusal 2) - in restart phase1).
PAGE6 Fascicle VI.7 - Rec. Q.711
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 pri 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
3) It is noted that the term "connection rejection" is used in Recommendation X.213 for
the "Reason" parameter values.
Fascicle VI.7 - Rec. Q.711 PAGE1
Parameter N-INFORM N-INFORM
request 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 S 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 RE T Type 1 contains the following
parameters:
- connection identification (for further study);
- receipt confirmation selection;
- expedited data selection;
- quality of service parameter set.
The RE T 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;
PAGE6 Fascicle VI.7 - Rec. Q.711
- 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 S 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 Request Connection identification
(for further study) Indication a)
N-RESET Request Originator
Indication Reason
Fascicle VI.7 - Rec. Q.711 PAGE1
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.
PAGE6 Fascicle VI.7 - Rec. Q.711
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
Fascicle VI.7 - Rec. Q.711 PAGE1
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.
PAGE6 Fascicle VI.7 - Rec. Q.711
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 N-UNITDATA
request indication
Called address X X
Calling address X X
Sequence control a) X
Return option
Fascicle VI.7 - Rec. Q.711 PAGE1
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
PAGE6 Fascicle VI.7 - Rec. Q.711
2.3 SCCP management
2.3.1 Description
The SCCP provides SCCP management procedures (see Recommendation Q.714, S
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
Fascicle VI.7 - Rec. Q.711 PAGE1
Affected DPC
Signalling Point
Status
2.3.2.2 Parameters
2.3.2.2.1 Address
See S 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).
PAGE6 Fascicle VI.7 - Rec. Q.711
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- 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 N-COORD N-COORD N-COORD
request indication response confirmatio
n
Affected subsystem X X X X
Subsystem multiplicity X X
indicator
2.3.2.3.2 STATE
"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
Fascicle VI.7 - Rec. Q.711 PAGE1
N-STATE N-STATE
request indication
Affected subsystem X X
User status X X
Subsystem multiplicity X
indicator
2.3.2.3.3 PCSTATE
The "N-PCSTATE pri (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".
PAGE6 Fascicle VI.7 - Rec. Q.711
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
Fascicle VI.7 - Rec. Q.711 PAGE1
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.
PAGE6 Fascicle VI.7 - Rec. Q.711
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 S 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) The need for this functions is for further study.
Fascicle VI.7 - Rec. Q.711 PAGE1
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, SS 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, S 3.4.
The address translation capabilities of the SCCP in relation to handling
OSI Network Service Access Points (NSAP) are for further study.
PAGE6 Fascicle VI.7 - Rec. Q.711
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.
S 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 S 2.1.1.3.2
is not required to support an OSI network layer service.
S 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.
S 2.2
Connectionless network service is still under study in Study Group VII and
is not defined in Recommendation X.213.
S 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 (S
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);
Fascicle VI.7 - Rec. Q.711 PAGE1
4) Facilities causing differences in the called and responding addresses
in N-CONNECT request and response (S 2.1.1.2.2, Rec. Q.711);
5) The need for Receipt Confirmation Service in SCCP (SS 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 (S 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 (S 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 (S
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 (S 3.2.4, Rec. Q.711);
14) Difference in QOS between permanent and temporary signalling
connections (S 4.1.2.2, Rec. Q.711);
15) SCCP management procedures for subsystem congestion (S 4.3, Rec. Q.711;
SS 3.11, 3.12, 3.15, Rec. Q.713; SS 5.1, 5.3, Rec. Q.714);
16) SCCP capabilities in OSI NSAP address translation (S 4.4, Rec. Q.711);
17) Possible need for diagnostic parameter (S 2.6, Rec. Q.712);
18) Constraints on order of optional parameter transmission (S 1.8, Rec.
Q.713);
19) Destination local reference coded as all ones (S 3.2, Rec. Q.713);
20) Source local reference coded as all ones (S 3.3, Rec. Q.713);
21) Alignment with X.96 call progress information (SS 3.11, 3.15, Rec.
Q.713);
22) Inclusion of routing failure causes as for return cause in
Recommendation Q.713, S 3.12 (S 3.15, Rec. Q.713);
23) Data parameter maximum length for Unitdata and Unitdata Service
messages (SS 4.10, 4.11, Rec. Q.713; SS 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 (S 1.14, Rec.
Q.714);
27) Classification of SCCP routing failure causes (S 2.4, Rec. Q.714);
28) Management procedures for non-dominant mode nodes/subsystems with more
than one backup (S 5.1, Rec. Q.714);
29) Receipt from a local originating subsystem of a message for a
prohibited subsystem (S 5.3.2.1, Rec. Q.714);
30) Possible introduction of a subsystem out of service denial message (S
5.3.5.3, Rec. Q.711);
31) Mathematical analysis of SCCP performance;
32) Recommendation Q.716 parameter valus (S 3, Rec. Q.716).
PAGE6 Fascicle VI.7 - Rec. Q.711
