home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-12-31 | 69.7 KB | 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
-
-