.rs .\" Troff code generated by TPS Convert from ITU Original Files .\" Not Copyright ( c) 1991 .\" .\" Assumes tbl, eqn, MS macros, and lots of luck. .TA 1c 2c 3c 4c 5c 6c 7c 8c .ds CH .ds CF .EQ delim @@ .EN .nr LL 40.5P .nr ll 40.5P .nr HM 3P .nr FM 6P .nr PO 4P .nr PD 9p .po 4P .rs \v | 5i' .sp 2P .LP \fBRecommendation\ Q.714\fR .RT .sp 2P .sp 1P .ce 1000 \fBSIGNALLING\ CONNECTION\ CONTROL\ PART\ PROCEDURES\fR .EF '% Fascicle\ VI.7\ \(em\ Rec.\ Q.714'' .OF '''Fascicle\ VI.7\ \(em\ Rec.\ Q.714 %' .ce 0 .sp 1P .LP \fB1\fR \fBIntroduction\fR .sp 1P .RT .sp 2P .LP 1.1 \fIGeneral characteristics of signalling connection control\fR \fIprocedures\fR .sp 1P .RT .sp 1P .LP 1.1.1 \fIPurpose\fR .sp 9p .RT .PP This Recommendation describes the procedures performed by the Signalling Connection Control Part (SCCP) of Signalling System No.\ 7 to provide both connection\(hyoriented and connectionless network services, and SCCP management services as defined in Recommendation\ Q.711. These procedures make use of the messages and information elements defined in Recommendation\ Q.712, whose formatting and coding aspects are specified in Recommendation\ Q.713. .RT .sp 1P .LP 1.1.2 \fIProtocol classes\fR .sp 9p .RT .PP The protocol used by the SCCP to provide network services is subdivided into four protocol classes, defined as follows: .RT .LP \(em Class\ 0: Basic connectionless class .LP \(em Class\ 1: Sequenced (MTP) connectionless class .LP \(em Class\ 2: Basic connection\(hyoriented class .LP \(em Class\ 3: Flow control connection\(hyoriented class .PP Due to the ongoing studies on the SCCP called and calling party address, the maximum of this value needs further study. It is also noted that the transfer of up to 255\ octets of user data is allowed when the SCCP called and calling party address do not include global title. .FE The connectionless protocol classes provide those capabilities that are necessary to transfer one Network Service Data Unit (NSDU), (i.e.,\ one user\(hyto\(hyuser information block) in the user data field of a \fIUnitdata\fR message. The maximum length of a NSDU is restricted to X\ octets , since segmenting and reassembly are not provided by protocol classes\ 0 and\ 1. .PP The connection\(hyoriented protocol classes (protocol classes\ 2 and\ 3) provide segmenting and reassembly capabilities. If a Network Service Data Unit is longer than 255\ octets, it is split into multiple segments at the originating node, prior to transfer in the \*Qdata\*U field of \fIData\fR messages. Each segment is less than or equal to 255\ octets. At the destination node, the NSDU is reassembled. .RT .sp 1P .LP 1.1.2.1 \fIProtocol class 0\fR .sp 9p .RT .PP Network Service Data Units passed by higher layers to the SCCP in the node of origin are delivered by the SCCP to higher layers in the destination node. They are transported independently of each other. Therefore, they may be delivered out\(hyof\(hysequence. Thus, this protocol class corresponds to a pure connectionless network service. .RT .sp 1P .LP 1.1.2.2 \fIProtocol class 1\fR .sp 9p .RT .PP In protocol class 1, the features of class 0 are complemented by an additional feature (i.e.,\ sequence control parameter associated with the N\(hyUNITDATA request primitive) which allows the higher layer to indicate to the SCCP that a given stream of NSDUs have to be delivered in\(hysequence. The .PP Signalling Link Selection (SLS) field is chosen by SCCP based on the value of the sequence control parameter. The SLS chosen for a stream of NSDUs with the same sequence control parameter will be identical. The SCCP will then encode the Signalling Link Selection (SLS) field in the routing label of messages relating to such NSDUs, so that their sequence is, under normal conditions, maintained by the signalling network as defined in Recommendation\ Q.704. Thus, this class corresponds to an enhanced connectionless service, where an additional sequencing feature is included. .bp .RT .sp 1P .LP 1.1.2.3 \fIProtocol class 2\fR .sp 9p .RT .PP In protocol class 2, bidirectional transfer of NSDUs between the user of the SCCP in the node of origin and the user of the SCCP in the destination node is performed by setting up a temporary or permanent signalling connection. A number of signalling connections may be multiplexed onto the same signalling relation, as defined in Recommendation\ Q.704; such a multiplexing is performed by using a pair of reference numbers, referred to as \*Qlocal\fR reference numbers\*U. Messages belonging to a given signalling connection will contain the same value of the SLS field to ensure sequencing as described in \(sc\ 1.1.2.2. Thus, this protocol class corresponds to a simple connection\(hyoriented network service, where SCCP flow control and missequence detection are not provided. .RT .sp 1P .LP 1.1.2.4 \fIProtocol class 3\fR .sp 9p .RT .PP In protocol class 3, the features of protocol class 2 are complemented by the inclusion of flow control, with its associated capability of expedited data transfer. Moreover, an additional capability of detection of message loss or mis\(hysequencing is included; in such a circumstance, the .PP signalling connection is reset and a corresponding notification is given by the SCCP to the higher layers. .RT .sp 1P .LP 1.1.3 \fISignalling connections\fR .sp 9p .RT .PP In all connection\(hyoriented protocol classes, a signalling connection between the nodes of origin and destination may consist of: .RT .LP \(em a single connection section, or .LP \(em a number of connection sections in tandem, which may belong to different interconnected signalling networks. .PP In the former case, the originating and destination nodes of the signalling connection coincide with the originating and destination nodes of a connection section. During the connection establishment phase, SCCP routing and relaying functions, as described in \(sc\ 2 of this Recommendation, may be required at one or more intermediate nodes. Once the signalling connection has been established, though, SCCP functions are not required at intermediate nodes. .PP In the latter case, at any intermediate node where a message is received from a connection section and has to be sent on another connection section, the SCCP routing and relaying functions are involved during connection establishment. In addition, SCCP functions are required at intermediate nodes during Data Transfer and Connection Release to provide the association of connection sections. .RT .sp 2P .LP 1.1.4 \fICompatibility and handling of unrecognized information\fR .sp 1P .RT .sp 1P .LP 1.1.4.1 \fIRules for forward compatibility\fR .sp 9p .RT .PP All implementations must recognize all messages in each protocol class offered, as indicated in Table\ 1/Q.713. .PP General rules for forward compatibility are specified in Recommendation\ Q.700. .RT .sp 1P .LP 1.1.4.2 \fIHandling of unrecognized messages or parameters\fR .sp 9p .RT .PP Any message with unrecognized message type value should be discarded. Any unrecognized parameter within a message should be ignored. Notification to the originator of the message in these two cases is for further study. .RT .sp 2P .LP 1.2 \fIOverview of procedures for connection\(hyoriented services\fR .sp 1P .RT .sp 1P .LP 1.2.1 \fIConnection establishment\fR .sp 9p .RT .PP When the SCCP functions at the node of origin receive a request to establish a signalling connection, the \*Qcalled party address\*U is analyzed to identify the node towards which a signalling connection should be established. The SCCP forwards a \fIConnection Request\fR (CR) message to that signalling point, using the MTP functions. .bp .PP The SCCP in the node receiving the CR message via the MTP functions examines the \*Qcalled party address\*U and one of the following actions takes place at the node: .RT .LP a) If the \*Qcalled party address\*U contained in the CR message corresponds to a user located in that signalling point and if the signalling connection may be established (i,e.,\ establishment of a signalling connection is agreed to by the SCCP and local user), a \fIConnection Confirm\fR (CC) message is returned. .LP b) If the \*Qcalled party address\*U does not correspond to a user at the signalling point, then information available in the message and at the node are examined to determine whether .LP an association of two connection sections is required at that node. .LP \(em If an association is required, then the SCCP establishes an (incoming) signalling connection section. Establishment of another (outgoing) connection section is initiated by sending a CR message towards the next node and this connection section is logically linked to the incoming connection section. .LP \(em If coupling of the connection section is not required in this node, no incoming or outgoing connection section is established. A CR message is forwarded towards the next destination using the MTP routing function. .PP If the SCCP receives a CR message and either the SCCP or the SCCP user does not wish to establish the connection, then a \fIConnection Refused\fR (CREF) message is transferred on the incoming connection section. .PP On receipt of a CC message, the SCCP completes the set\(hyup of a connection section. Furthermore, if coupling of two adjacent connection sections is needed, a further CC message is forwarded to the preceding node. .PP If no coupling of adjacent connection sections was needed during set\(hyup in the forward direction, the CC\ message can be sent directly to the node of origin even if a number of intermediate SCCP nodes was passed in the forward direction. The OPC of the node of origin is transmitted within the \*Qcalling party address\*U Field. .PP When the CR and CC messages have been exchanged between all the involved nodes as above described, and the corresponding indications have been given to the higher layer functions in the nodes of origin and destination, then the signalling connection is established and transmission of messages may commence. .RT .sp 1P .LP 1.2.2 \fIData transfer\fR .sp 9p .RT .PP Transfer of each NSDU is performed by one or more \fIData\fR | DT) messages; a \fImore\(hydata\fR | ndication is used if the NSDU is to be split among more than one DT\ message. If protocol class\ 3 is used, then SCCP flow control is utilized over each connection section of the signalling connection. If, in such a protocol class, abnormal conditions are detected, then the appropriate actions are taken on the signalling connection .PP (e.g.,\ reset). Moreover in such a protocol class, expedited data may be sent using one \fIExpedited Data\fR message that bypasses the flow control procedures applying to \fIData\fR messages. .PP A limited amount of data may also be transferred in the \fIConnection\fR \fIRequest\fR ,\fR \fIConnection Refused\fR | nd \fIConnection Released\fR messages. .RT .sp 1P .LP 1.2.3 \fIConnection release\fR .sp 9p .RT .PP When the signalling connection is terminated, a release sequence takes place by means of two messages called \fIReleased\fR | nd \fIRelease\fR \fIComplete\fR (RLC). The RLC message is normally sent in reaction to the receipt of a RLSD message. .RT .sp 2P .LP 1.3 \fIOverview of procedures for connectionless services\fR .sp 1P .RT .sp 1P .LP 1.3.1 \fIGeneral\fR .sp 9p .RT .PP When the SCCP functions at the node of origin receive from an SCCP user an NSDU to be transferred by the protocol class\ 0 or 1\ connectionless service, the \*Qcalled party address\*U and other relevant parameters, if required, are analyzed to identify the node towards which the message should be sent. The NSDU is then included as the \*Qdata\*U parameter in a \fIUnitdata\fR (UDT) message, .PP which is sent towards the node using the MTP functions. Upon receipt of the UDT message, the SCCP functions at that node perform the routing analysis as described in \(sc\ 2 of this Recommendation and, if the destination of the UDT message is a local user, deliver the NSDU to the local higher layer functions. If the \*Qcalled party address\*U is not at that node, then the UDT message is forwarded to the next node. This process continues until the NSDU has reached the \*Qcalled party address\*U. .bp .RT .sp 1P .LP 1.4 \fIStructure of the SCCP and contents of specification\fR .sp 9p .RT .PP The basic structure of the SCCP appears in Figure 1/Q.714. It consists of four functional blocks as follows: .RT .LP a) \fISCCP connection\(hyoriented control:\fR | ts purpose is to control the establishment and release of signalling connections and to provide for data transfer on signalling connections. .LP b) \fISCCP connectionless control:\fR | ts purpose is to provide for the connectionless transfer of data units. .LP c) \fISCCP management:\fR | ts purpose is to provide capabilities, in addition to the Signalling Route Management and flow control .LP functions of the MTP, to handle the congestion or failure of either the SCCP user or the signalling route to the SCCP user. .LP d) \fISCCP routing:\fR | pon receipt of a message from the MTP or from functions\ a) or b)\ above, SCCP routing provides the necessary routing functions to either forward the message to the MTP for transfer, or pass the message to functions\ a) or\ b) above. A message whose \*Qcalled party address\*U is a local user is passed to functions\ a or\ b, while one destined for a remote user is forwarded to the MTP for transfer to a distant SCCP user. .PP Section 2 of this specification describes the addressing and routing functions performed by the SCCP. Section\ 3 specifies the procedures for the connection\(hyoriented services (protocol classes\ 2\(hy3). Section\ 4 specifies the procedures for the connectionless services (protocol classes\ 0 and\ 1). Section\ 5 specifies the SCCP management procedures. .sp 2P .LP \fB2\fR \fBAddressing and routing\fR .sp 1P .RT .sp 1P .LP 2.1 \fISCCP addressing\fR .sp 9p .RT .PP The \*Qcalled and calling party addresses\*U contain the information necessary for the SCCP to determine an originating and destination node. In the case of the connection\(hyoriented procedures, the addresses are the originating and destination points of the signalling connection, while in the case of the connectionless procedures, the addresses are the originating and destination points of the message. .PP When transferring connection\(hyoriented or connectionless messages, two basic categories of addresses are distinguished by SCCP routing: .RT .LP 1) \fIGlobal Title\fR \ \(em\ A global title is an address, such as dialled\(hydigits, which does not explicitly contain information that would allow routing in the signalling network, that is the translation function of the SCCP is required. This translation function could be performed on a distributed basis or on a centralized basis. The last case, where a request for translation is sent to a centralized data base, may be .LP accomplished, for example, with transaction capabilities (TC). This matter is for further study. .LP In case of an E.164\(hybased global title with the nature of address indicator included, the sending sequence of address information will be the country code, followed by the national (significant) number. Within the destination signalling network, the address information may be the subscriber number or the national (significant) number, by choice of the value of nature of address indicator, as required by the administration concerned. .LP 2) \fIDPC + SSN\fR \ \(em\ A Destination Point Code and Subsystem Number allows direct routing by the SCCP and MTP, that is, the translation function of the SCCP is not required. .sp 1P .LP 2.2 \fISCCP routing principles\fR .sp 9p .RT .PP The SCCP routing control (SCRC) receives messages from the Message Transfer Part for routing and discrimination, after they have been received by the MTP from another node in the signalling network. SCRC also receives .PP internal messages from SCCP connection\(hyoriented control (SCOC) and connectionless control (SCLC) and performs any necessary routing functions (e.g.,\ address translation) before passing them to the MTP for transport in the signalling network or back to the SCCP connection\(hyoriented or connectionless control. .bp .RT .LP .rs .sp 47P .ad r \fBFigure 1/Q.714, p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 2.2.1 \fIReceipt of SCCP message transferred by the MTP\fR .sp 9p .RT .PP A message transferred by the MTP that requires routing will include the \*Qcalled party address\*U parameter giving information for routing the message. These messages currently include the \fIConnection Request\fR message and all types of connectionless messages. Other messages are passed to connection\(hyoriented control for processing. .PP If the \*Qcalled party address\*U parameter is used for routing, it can take the following information: .RT .LP 1) \fISubsystem Number (SSN) only\fR \ \(em\ This indicates that the receiving SCCP is the termination point of the message. The SSN is used to determine the local subsystem. .LP 2) \fIGlobal Title (GT) only\fR \ \(em\ This indicates that translation is required. Translation of the Global Title results in a new destination point code (DPC) for routing the message, and possibly a new SSN or GT or both in the \*Qcalled party address\*U. .LP 3) \fISSN + GT\fR \ \(em\ In this case, the address indicator information is used to determine whether the SSN or the GT should be used for routing and processing via items\ 1) or\ 2) above, respectively. .sp 1P .LP 2.2.2 \fIMessages from connection\(hyoriented or connectionless control to\fR \fISCCP routing control\fR .sp 9p .RT .PP Addressing information, indicating the destination of the message, is included with every internal message received from connection\(hyoriented or connectionless control. For connectionless messages, this addressing information is obtained from the \*Qcalled address\*U parameter associated with the N\(hyUNITDATA REQUEST primitive. For \fIConnection\(hyRequest\fR messages received by SCCP routing, the addressing information is obtained from the \*QCalled address\*U parameter associated with the N\(hyCONNECT REQUEST primitive. For connection\(hyoriented messages other than a \fIConnection Request\fR message, the .PP addressing information (i.e.,\ the DPC) is that associated with the connection section. The addressing information can take the following forms: .RT .LP 1) DPC .LP 2) DPC + (SSN or GT or both) .LP 3) GT .LP 4) GT + SSN .PP The first form applies to connection\(hyoriented messages except the \fIConnection Request\fR | message. The last three forms apply to connectionless messages and to the \fIConnection Request\fR message. .sp 1P .LP 2.2.2.1 \fIDPC present\fR .sp 9p .RT .PP If the DPC is present in the addressing information, then the DPC is passed to the MTP using the MTP\(hyTRANSFER request primitive and: .RT .LP 1) if no other addressing information is available, no \*Qcalled party address\*U is provided in the message; .LP 2) if a SSN or GT or both are available, this information is used in the \*Qcalled party address\*U with an indication of which is to be used for routing. .PP If the DPC is the node itself, then the information is passed to the specified internal subsystem. .sp 1P .LP 2.2.2.2 \fITranslation required\fR .sp 9p .RT .PP If the DPC is not present, then a global title translation is required before the message can be sent out. Translation results in a DPC and possibly a new SSN or new GT or both. If the GT and/or SSN resulting from a global title translation is different from the GT and/or SSN which was previously included in the called party address, the newly produced GT and/or SSN replaces the existing one. The routing procedures then continue as per \(sc\ 2.2.2.1 .RT .sp 1P .LP 2.3 \fISCCP routing\fR .sp 9p .RT .PP The SCCP routing functions are based on information contained in the \*Qcalled party address\*U. .bp .RT .sp 1P .LP 2.3.1 \fIReceipt of SCCP message transferred by the MTP\fR .sp 9p .RT .PP One of the following actions is taken by SCCP routing upon receipt of a message from the Message Transfer Part. The message is received by the SCCP when the MTP invokes a MTP\(hyTRANSFER INDICATION. .RT .LP 1) If the message is a connection\(hyoriented message other than a \fIConnection Request\fR | (CR) message, then SCCP routing passes the message to connection\(hyoriented control. .LP 2) If the routing indicator in the \*Qcalled party address\*U does not indicate route on global title, then SCCP routing checks the status of the subsystem. .LP a) If the subsystem is available, the message is passed, based on the message type, to either connection\(hyoriented control or connectionless control. .LP b) If the system is unavailable and: .LP \(em the message is a connectionless message, then the message return procedure is initiated; .LP \(em the message is a connection\(hyoriented message (a CR message), then the connection refusal procedure is initiated. .LP In addition, if the subsystem is failed, SCCP management is notified that a message was received for a failed subsystem. .LP 3) If the routing indicator in the \*Qcalled party address\*U indicates route on global title, a translation of the global title must be performed. .LP a) If the translation of the global title exists, and both the DPC and SSN are determined, then: .LP i) if the DPC is the node itself, then the procedures in 2) above are followed; .LP ii) if the DPC is not the node itself, the DPC and SSN are available, and the message is a connectionless message, then the MTP\(hyTRANSFER REQUEST primitive is invoked; .LP iii) if the DPC is not the node itself, the DPC and SSN are available, and the message is a connection\(hyoriented message, then: .LP \(em if an association of connection sections is required, the message is passed to connection\(hyoriented control; .LP \(em if no association of connection sections is required, the MTP\(hyTRANSFER REQUEST primitive is invoked; .LP iv) if the DPC is not the node itself, and the DPC and/or SSN are not available and .LP \(em the message is a connectionless message, then the message return procedure is initiated; .LP \(em the message is a connection\(hyoriented message (a CR message), then the connection refusal procedure is initiated. .LP b) If the translation of the global title exists and only a DPC or DPC + new GT is determined, then: .LP i) if the DPC is available, and the message is a connectionless message, then the MTP\(hyTRANSFER REQUEST primitive is invoked; .LP ii) if the DPC is available, and the message is a connection\(hyoriented message, then: .LP \(em if an association of the connection sections is required, then the message is passed to connection\(hyoriented control; .LP \(em if no association of the connection section is required, then the MTP\(hyTRANSFER REQUEST primitive is invoked. .LP iii) if the DPC is not available and .LP \(em the message is a connectionless message, then the message return procedure is initiated; .LP \(em the message is a connection\(hyoriented message (a CR message), then the connection refusal procedure is initiated. .LP c) If the translation of the global title does not exist, and .LP \(em the message is a connectionless message, then the message return procedure is initiated; .LP \(em the message is a connection\(hyoriented message (a CR message), then the connection refusal procedure is initiated. .bp .sp 1P .LP 2.3.2 \fIMessages from connectionless or connection\(hyoriented control to\fR \fISCCP routing control\fR .sp 9p .RT .PP One of the following actions is taken by SCCP routing upon receipt of a message from connectionless control or connection\(hyoriented control. .RT .LP 1) If the message is a \fIConnection Request\fR | message at an intermediate node (where connection sections are being associated), and: .LP a) the DPC is available, then the MTP\(hyTRANSFER REQUEST primitive is invoked; .LP b) the DPC is not available, then the connection refusal procedure is initiated. .LP 2) If the message is a connection\(hyoriented message other than a \fIConnection Request\fR | message, and: .LP a) the DPC is available, then the MTP\(hyTRANSFER REQUEST primitive is invoked; .LP b) the DPC is not available, then the connection release procedure is initiated. .LP 3) If the \*QCalled address\*U in the primitive associated with a \fIConnection Request\fR | or connectionless message includes a DPC, and: .LP a) the DPC and SSN are available, then the MTP\(hyTRANSFER REQUEST primitive is invoked; .LP b) the DPC and/or SSN are not available, then: .LP \(em for connectionless messages, the message return procedure is initiated; .LP \(em for connection\(hyoriented messages (CR messages), the connection refusal procedure is initiated. .LP The function of routing between local subsystems is implementation dependent. .FE c) the DPC is the node itself, then the procedures in \(sc\ 2.3.1, 2) above are followed. .LP 4) If the \*QCalled address\*U in the primitive associated with a \fIConnection Request\fR | or connectionless message does not include a DPC, then a translation of the global title must be performed. .LP a) If the translation of the global title exists, and both the DPC and SSN are determined, then: .LP i) if the DPC is the node itself, then the procedures in \(sc\ 2.3.1, 2), above are followed. .LP ii) if the DPC is not the node itself and DPC and SSN are available, then the MTP\(hyTRANSFER REQUEST primitive is invoked; .LP iii) if the DPC is not the node itself, and the DPC and/or SSN are not available and: .LP \(em the message is a connectionless message, then the message return procedure is initiated; .LP \(em the message is a connection\(hyoriented message (a CR message), then the connection refusal procedure is initiated. .LP b) If the translation of the global title exists and only a DPC or DPC + new GT is determined, then .LP i) if the DPC is available, then the MTP\(hyTRANSFER REQUEST primitive is invoked; .LP ii) if the DPC is not available and: .LP \(em the message is a connectionless message, then the message return procedure is initiated; .LP \(em the message is a connection\(hyoriented message (a CR message), then the connection refusal procedure is initiated. .LP c) If the translation of the global title does not exist, and: .LP \(em the message is a connectionless message, then the message return procedure is initiated; .LP \(em the message is a connection\(hyoriented message (a CR message), then the connection refusal procedure is initiated. .bp .sp 1P .LP 2.4 \fIRouting failures\fR .sp 9p .RT .PP The SCCP recognizes a number of reasons for failure in SCCP routing control. Examples of these reasons are: .RT .LP 1) translation does not exist for addresses of this nature; .LP 2) translation does not exist for this specific address; .LP 3) network/subsystem failure; .LP 4) network/subsystem congestion, and .LP 5) unequipped user. .PP The precise classification of the causes by which such failures are recognized is for further study. .PP When SCCP routing is unable to transfer a message due to the unavailability of a Point Code or Subsystem, one of above reasons is indicated in the \fIConnection Refused\fR message, the \fIConnection Released\fR message or the \fIUnitdata Service\fR message. .RT .LP \fB3\fR \fBConnection\(hyoriented procedures\fR .sp 1P .RT .sp 2P .LP 3.1 \fIConnection establishment\fR .sp 1P .RT .sp 1P .LP 3.1.1 \fIGeneral\fR .sp 9p .RT .PP The connection establishment procedures consist of the functions required to establish a temporary signalling connection between two users of the Signalling Connection Control Part. .PP The connection establishment procedures are initiated by a SCCP user by invoking the N\(hyCONNECT request primitive. .PP The ISDN\(hyUP may initiate an SCCP connection in the same way as any other user, but may also request the SCCP to initiate a connection and return the information to the ISDN\(hyUP for transmission in a call set\(hyup message. .PP The signalling connections between two users of the Signalling Connection Control Part, which are referred to by the \*QCalled/Calling address\*U parameters in the N\(hyCONNECT REQUEST primitive, may be realized by the establishment of one or more connection sections. The SCCP user is not aware of how the SCCP provides the signalling connection (e.g.\ by one or more than one connection sections). .PP The realization of a signalling connection between two SCCP users then can be described by the following components: .RT .LP 1) one or more connection sections; .LP 2) an originating node, where the \*QCalling address\*U is located; .LP 3) zero or more intermediate nodes, where, for this signalling connection, there is no distribution to a SCCP user; and .LP 4) a destination node, where the \*QCalled address\*U is located. .PP The \fIConnection Request\fR | essage and the \fIConnection Confirm\fR | essage are used to set up connection sections. .sp 1P .LP 3.1.2 \fILocal reference numbers\fR .sp 9p .RT .PP During connection establishment both a source and destination local reference number are assigned independently to a connection section. .PP Source and destination local reference numbers are assigned at connection section set\(hyup for a permanent connection section. .PP Once the destination reference number is known, it is a mandatory field for all messages transferred on that connection section. .PP Each node will select the local reference that will be used by the remote node as the destination local reference number field on a connection section for data transfer. .PP The local reference numbers remain unavailable for use on other connection sections until the connection section is released and the reference numbers are removed from their frozen state. See also \(sc\ 3.3.2. .bp .RT .sp 2P .LP 3.1.3 \fINegotiation procedures\fR .sp 1P .RT .sp 1P .LP 3.1.3.1 \fIProtocol class negotiation\fR .sp 9p .RT .PP During connection establishment it is possible to negotiate the protocol class of a signalling connection between two SCCP users. .PP The N\(hyCONNECT REQUEST primitive contains a parameter, the \*QQuality of service parameter set\*U, with the preferred quality of service proposed by the SCCP user for the signalling connection. .PP The SCCP at the originating, intermediate and destination nodes may alter the protocol class on a signalling connection so that the quality of service assigned to the signalling connection is less restrictive (e.g.,\ a protocol class\ 2 connection may be provided if a protocol class\ 3 .PP connection is proposed). Information concerning the present proposed protocol class within the SCCP is carried in the \fIConnection Request\fR message and the assigned protocol class appears in the \fIConnection Confirm\fR message. .PP At the destination node the SCCP user is notified of the proposed protocol class using the N\(hyCONNECT INDICATION primitive. .PP The protocol class of a signalling connection may also be altered by the Called SCCP user in the same manner (i.e.\ less restrictive) when invoking the N\(hyCONNECT RESPONSE primitive. .PP The Calling SCCP user is informed of the quality of service selected on the signalling connection using the N\(hyCONNECT CONFIRMATION primitive. .RT .sp 1P .LP 3.1.3.2 \fIFlow control credit negotiation\fR .sp 9p .RT .PP During connection establishment it is possible to negotiate the window size to be used on a signalling connection for the purpose of flow control. This window size remains fixed for the life of the signalling connection. The credit field in the CONNECTION REQUEST and CONNECTION\fR CONFIRM\fR messages is used to indicate the window size. .PP The N\(hyCONNECT REQUEST primitive contains a parameter, the \*QQuality of service parameter set\*U with the preferred quality of service proposed by the SCCP user for the signalling connection. .PP The SCCP at the originating, intermediate and destination nodes may alter the window size on a signalling connection so that the quality of service assigned to the signalling connection is less restrictive (e.g.,\ a smaller window size may be provided). Information concerning the present proposed window size within the SCCP is carried in the \fIConnection Request\fR message and the assigned window size appears in the \fIConnection Confirm\fR message. .PP At the destination node the SCCP user is notified of the proposed window size using the N\(hyCONNECT indication primitive. .PP The window size of a signalling connection may also be altered by the Called SCCP user in the same manner (i.e. less restrictive) when invoking the N\(hyCONNECT RESPONSE primitive. .PP The Calling SCCP user is informed of the quality of service selected on the signalling connection using the N\(hyCONNECT confirm primitive. .RT .sp 2P .LP 3.1.4 \fIActions at the origination node\fR .sp 1P .RT .sp 1P .LP 3.1.4.1 \fIInitial actions\fR .sp 9p .RT .PP The N\(hyCONNECT REQUEST primitive is invoked by the SCCP user at the originating node to request the establishment of a signalling connection to the \*QCalled address\*U contained in the primitive. The node determines if resources are available. .PP If resources are not available, then the connection refusal procedure is initiated. .PP If resources are available, then the following actions take place at the originating node: .RT .LP 1) A source local reference number and an SLS code are assigned to the connection section. .LP 2) The \*QCalled address\*U is associated with the connection section. .LP 3) The proposed protocol class is determined for the connection section. .bp .LP 4) If the protocol class provides for flow control, then an initial credit is indicated in the \fIConnection Request\fR message. .LP 5) The \fIConnection Request\fR | essage is then forwarded to the SCCP routing function for transfer. .LP 6) A timer T(conn\ est) is started. .PP The ISDN\(hyUP may request the SCCP to set up a SCCP signalling connection and return the information normally carried in a \fIConnection\fR \fIrequest\fR | message to the ISDN\(hyUP for transmission in a call set\(hyup message. .PP When the ISDN\(hyUP notifies the SCCP of the need for the connection, using the REQUEST Type\ 1 interface element, the SCCP determines if resources are available. .PP If resources are not available, then the connection refusal procedure is initiated. If resources are available, then the following actions take place at the origination node: .RT .LP 1) A source local reference number and an SLS code is assigned to the connection section. .LP 2) An indication that the call request is from the ISDN\(hyUP is associated with the connection section. .LP 3) The proposed protocol class is determined for the connection section. .LP 4) If the protocol class provides for flow control, then an initial credit is indicated. .LP 5) The information that would normally be included in a Connection Request message is passed to the ISDN\(hyUP for transfer using the REPLY interface element. .LP 6) A timer T(conn\ est) is started. .sp 1P .LP 3.1.4.2 \fISubsequent actions\fR .sp 9p .RT .PP When an originating node receives a \fIConnection Confirm\fR | essage, the following actions are performed: .RT .LP 1) The protocol class and initial credit for flow control of the connection section are updated if necessary. .LP 2) The SCCP user is informed of the successful establishment of the signalling connection using the N\(hyCONNECT CONFIRMATION primitive. .LP 3) The received local reference number is associated with the connection section. .LP 4) The timer T(conn\ est) is stopped. .LP 5) The inactivity control timers, T(ias) and T(iar), are started. .PP When the SCCP user at an origination node invokes the N\(hyDISCONNECT REQUEST primitive, no action is taken prior to receipt of a \fIConnection\fR \fIConfirm\fR or a \fIConnection Refused\fR message or expiration of the connection establishment timer. .PP When an originating node receives a \fIConnection Refused\fR | essage, the connection refusal procedure is completed at the origination node (see \(sc\ 3.2.3). .PP When the connection establishment timer at the origination node expires, the N\(hyDISCONNECT INDICATION primitive is invoked, the resources associated with the connection section are released, and the local reference number is frozen. .RT .sp 2P .LP 3.1.5 \fIActions at an intermediate node\fR .sp 1P .RT .sp 1P .LP 3.1.5.1 \fIInitial actions\fR .sp 9p .RT .PP When a \fIConnection Request\fR | essage is received at a node and the SCCP routing and discrimination function determines that the \*Qcalled party .PP address\*U is not a local SCCP user and that a coupling is required at this node, the intermediate node determines if resources are available to establish the connection section. .PP If resources are not available at the node, then the connection refusal procedure is initiated. .bp .PP If resources are available at the node, then the following actions are performed: .RT .LP 1) A local reference number and an SLS code are assigned to the incoming connection section. (\fINote\fR \ \(em\ As an implementation option, a local reference number may be assigned later upon reception of a \fIConnection Confirm\fR message.) .LP 2) A connection section is set up to the remote node determined by SCCP Routing: .LP \(em A local reference number and an SLS code are assigned to the outgoing connection section. .LP \(em The protocol class is proposed. .LP \(em An initial credit for flow control is assigned, if appropriate. .LP \(em The \fIConnection Request\fR | essage is forwarded to the SCCP Routing with the same addressing information as found in the incoming \fIConnection Request\fR message. .LP \(em The timer T(conn\ est) is started. .LP 3) An association is made between the incoming and outgoing connection sections. .PP The ISDN\(hyUP informs the SCCP that a connection request has been received using the REQUEST Type\ 2 interface element. The ISDN\(hyUP passes the information contained in the ISDN\(hyUP set\(hyup message to the SCCP and indicates that a coupling is required at this node. The SCCP at the intermediate node then determines if resources are available to establish the connection section. .PP If resources are not available at the node, then the connection refusal procedure is initiated. .PP If resources are available at the node, then the following actions are performed: .RT .LP 1) A local reference number and an SLS code are assigned to the incoming connection section. .LP 2) A local reference number and an SLS code is assigned to an outgoing connection section. .LP 3) A protocol class is proposed. .LP 4) An initial credit for flow control is assigned if appropriate. .LP 5) An association is made between the incoming and outgoing connection sections. .LP 6) The information that would normally be included in a conection request message is passed to the ISDN\(hyUP for transfer in the REPLY interface element. .LP 7) The timer T(conn\ est) is started. .sp 1P .LP 3.1.5.2 \fISubsequent actions\fR .sp 9p .RT .PP When an intermediate node receives a \fIConnection Confirm\fR | essage, the following actions are performed: .RT .LP 1) The source local reference number in the \fIConnection\fR \fIConfirm\fR | essage is associated with the outgoing connection section. .LP 2) The protocol class and credit for the connection section are assigned and identical to those found in the received \fIConnection Confirm\fR message. .LP 3) A \fIConnection Confirm\fR | essage is transferred, using the SCCP routing function, to the originating node of the associated connection section. The protocol class and credit are identical to those indicated in the received \fIConnection Confirm\fR message. .LP 4) The timer T(conn\ est) is stopped. .LP 5) The inactivity control timers, T(ias) and T(iar), are started. .PP When an intermediate node receives a \fIConnection Refused\fR | essage, the connection refusal procedure is completed at that node (see \(sc\ 3.2.2). .PP When the connection establishment timer expires at an intermediate node, the following actions are performed: .RT .LP 1) The resources associated with the connection are released. .LP 2) The local reference number is frozen (see \(sc\ 3.3.2). .LP 3) If the connection section was established using a REQUEST interface element, then the N\(hyDISCONNECT INDICATION primitive is invoked. .LP 4) The connection refusal procedure is initiated on the associated connection section (see \(sc\ 3.2.1). .bp .sp 2P .LP 3.1.6 \fIActions at destination node\fR .sp 1P .RT .sp 1P .LP 3.1.6.1 \fIInitial actions\fR .sp 9p .RT .PP When a \fIConnection Request\fR | essage is received at a node, and the SCCP routing and discrimination function determines that the \*Qcalled party address\*U is a local user, the destination node determines if resources are available to establish the connection section. .PP If resources are not available at the node, then the connection refusal procedure is initiated. .PP If the resources are available at the node, then the following actions are performed: .RT .LP 1) The protocol class is determined for the connection section. (\fINote\fR \ \(em\ As an implementation option, a local reference number may also be assigned for the connection section.) .LP 2) An initial credit for flow control is assigned if appropriate. .LP 3) The node informs the SCCP user of a request to establish a connection using the N\(hyCONNECT INDICATION primitive. .PP When the ISDN\(hyUP informs the SCCP that a connection request has been received using the REQUEST Type\ 2 interface element, the ISDN\(hyUP passes the information contained in the ISDN\(hyUP set\(hyup message to the SCCP, and informs the SCCP that the information is for a local user. The SCCP at the destination node determines if resources are available to establish the connection section. .PP If resources are not available at the node, then the connection refusal procedure is initiated. .PP If resources are available at the node, then the following actions are performed: .RT .LP 1) The protocol class is determined for the connection section. .LP 2) An initial credit for flow control is assigned if appropriate. .LP 3) The node informs the ISDN\(hyUP of the request to establish a connection using the N\(hyCONNECT INDICATION primitive. .sp 1P .LP 3.1.6.2 \fISubsequent actions\fR .sp 9p .RT .PP When a N\(hyCONNECT RESPONSE primitive is invoked by the SCCP user at a destination node, the following actions are performed: .RT .LP 1) A local reference number and an SLS code are assigned to the incoming connection section. .LP 2) The protocol class and credit are updated for the connection section if necessary. .LP 3) A \fIConnection Confirm\fR | message is transferred, using the SCCP routing function, to the originating node of the connection section. .LP 4) The inactivity control timers, T(ias) and T(iar), are started. .sp 1P .LP 3.2 \fIConnection refusal\fR .sp 9p .RT .PP The purpose of the connection refusal procedure is to indicate to the Calling SCCP user function that the attempt to set up a signalling connection section was unsuccessful. .RT .sp 1P .LP 3.2.1 \fIActions at node initiating connection refusal\fR .sp 9p .RT .PP The connection refusal procedure is initiated by either the SCCP user or the SCCP itself: .RT .LP 1) The SCCP user at the destination node .LP a) uses the N\(hyDISCONNECT REQUEST (originator indicates \*Quser initiated\*U) after the SCCP has invoked an N\(hyCONNECT indication primitive. This is the case when the SCCP at the destination node has received the connection request directly from a preceding SCCP. .LP b) uses the refusal indicator in the REQUEST Type 2 interface element when the SCCP user has received the connection request embedded in a user part message. .bp .LP If the reason for the refusal is \*Qdestination address unknown\*U, then the maintenance function is alerted. .FE 2) The SCCP initiates connection refusal (originator indicates \*Qnetwork initiated\*U) due to: .LP a) limited resources at an originating, intermediate or destination node, or .LP b) expiration of the connection establishment timer at an originating or intermediate node. .PP Initiation of the connection refusal procedure by either the SCCP or the user results in the transfer of a \fIConnection Refused\fR | essage on the connection section. The refusal cause contains the value of the originator in the primitives; if the refusal procedure has been initiated by using the refusal indicator in the REQUEST Type\ 2 interface element, the refusal cause contains \*QSCCP user originated\*U. .PP At the originating node, a connection refusal is initiated by invoking N\(hyDISCONNECT INDICATION primitive. .PP If the connection refusal procedure is initiated at an intermediate node due to lack of resources, then a \fIConnection Refused\fR | message is transferred on the incoming connection section. .PP If the connection refusal procedure is initiated at an intermediate node due to expiration of the connection establishment timer, then the connection release procedure is initiated on that connection section (see \(sc\ 3.3.4.1) and a \fIConnection Refused\fR message is transferred on the associated connection section. .PP In either of the two above cases at an intermediate node, if the connection set\(hyup was initiated using a REQUEST interface element, then the SCCP user is informed by invoking the N\(hyDISCONNECT INDICATION primitive. .RT .sp 1P .LP 3.2.2 \fIActions at intermediate node not initiating connection refusal\fR .sp 9p .RT .PP When a \fIConnection Refused\fR | essage is received on a connection section, the following actions are performed: .RT .LP 1) The resources associated with the connection section are released and the timer T(conn\ est) is stopped . .LP 2) If the connection was established using a REQUEST interface element, then the SCCP user is informed by invoking the N\(hyDISCONNECT INDICATION primitive. .LP 3) A \fIConnection Refused\fR | essage is transferred on the associated connection section. .LP 4) The resources associated with the associated connection section are released. .sp 1P .LP 3.2.3 \fIActions at the origination node not initiating connection\fR \fIrefusal\fR .sp 9p .RT .PP When a \fIConnection Refused\fR | essage is received on a connection section, the following actions are performed: .RT .LP 1) The resources associated with the connection section are released and the timer T(conn\ est) is stopped . .LP 2) The SCCP user is informed by invoking the N\(hyDISCONNECT INDICATION primitive. .sp 2P .LP 3.3 \fIConnection release\fR .sp 1P .RT .sp 1P .LP 3.3.1 \fIGeneral\fR .sp 9p .RT .PP The connection release procedures consist of the functions required to release a temporary signalling connection between two users of the Signalling Connection Control Part. Two messages are required to initiate and complete connection release: \fIReleased\fR and \fIRelease Complete\fR . .PP The release may be performed: .RT .LP a) by either or both of the SCCP users to release an established connection. .LP b) by the SCCP to release an established connection. .PP All failures to maintain a connection are indicated in this way. .bp .sp 1P .LP 3.3.2 \fIFrozen reference\fR .sp 9p .RT .PP The purpose of the frozen reference function is to prevent the initiation of incorrect procedures as a connection section due to receipt of a message, which is associated with a previously established connection section. .PP When a connection section is released, the local reference number associated with the connection section is not immediately available for reuse on another connection section. A mechanism should be chosen to sufficiently .PP reduce the probability of erroneously associating a message with a connection section. This particular mechanism is implementation dependent. .RT .sp 2P .LP 3.3.3 \fIActions at an end node initiating connection release\fR .sp 1P .RT .sp 1P .LP 3.3.3.1 \fIInitial actions\fR .sp 9p .RT .PP When a connection release is initiated at an end node of a signalling connection, by the SCCP user invoking a N\(hyDISCONNECT REQUEST primitive or by the node itself, the following actions are performed at the initiating node: .RT .LP 1) A \fIReleased\fR | essage is transferred on the connection section. .LP 2) A release timer T(rel) is started. .LP 3) If the release was initiated by the SCCP, then a N\(hyDISCONNECT INDICATION primitive is invoked. .LP 4) The inactivity control timers, T(ias) and T(iar), if still running, are stopped. .sp 1P .LP 3.3.3.2 \fISubsequent actions\fR .sp 9p .RT .PP The following actions are performed at the originating node on a connection section for which a \fIReleased\fR | essage has been previously transferred: .RT .LP 1) When a \fIRelease Complete\fR | r \fIReleased\fR | essage is received, the resources associated with the connection are released, the timer, T(rel), is stopped, and the local reference number is frozen. .LP 2) When the release timer expires, a \fIReleased\fR | essage is transferred on the connection section. The sending of the \fIReleased\fR message is repeated every\ 4\(hy15 seconds for an interval of up to one minute. At this point a maintenance function is alerted. .sp 1P .LP 3.3.4 \fIActions at intermediate node\fR .sp 9p .RT .PP The connection release procedure is initiated at an intermediate node by the SCCP or by reception of a \fIReleased\fR | essage on a connection section. .RT .sp 1P .LP 3.3.4.1 \fIInitial actions\fR .sp 9p .RT .PP When a \fIReleased\fR | essage is received on a connection section, the following actions then take place: .RT .LP 1) A \fIRelease Complete\fR | essage is transferred on the connection section, the resources associated with the connection are released and the local reference number is frozen. .LP 2) A \fIReleased\fR | essage is transferred on the associated connection section; the reason is identical to the reason in the received message. .LP 3) If the connection was established using a REQUEST interface element, then a N\(hyDISCONNECT INDICATION primitive is invoked. .LP 4) The release timer, T(rel), is started on the associated connection. .LP 5) The inactivity control timers, T(ias) and T(iar), if still running, are stopped on both connection sections. .bp .PP When the connection release procedure is initiated by the SCCP at the intermediate node during the data transfer phase, the following actions take place on both of the connection sections: .LP 1) A \fIReleased\fR | essage is transferred on the connection section. .LP 2) If the connection section was established using an interface element, then a N\(hyDISCONNECT INDICATION primitive is invoked. .LP 3) The release timer, T(rel), is started. .LP 4) The inactivity control timers, T(ias) and T(iar), if still running, are stopped on both connection sections. .sp 1P .LP 3.3.4.2 \fISubsequent actions\fR .sp 9p .RT .PP The following actions are performed at an intermediate node during connection release: .RT .LP 1) When a \fIRelease Complete\fR | r \fIReleased\fR | essage is received on a connection section, the resources associated with the connection are released, the timer T(rel) is stopped, and the local reference number is frozen. .LP 2) When the release timer expires, a \fIReleased\fR | essage is transferred on the connection section. The sending of the Released message is repeated every 4\(hy15\ seconds for an interval .LP of up to one minute. At this point a maintenance function is alerted. .sp 1P .LP 3.3.5 \fIActions at an end node not initiating connection release\fR .sp 9p .RT .PP When a \fIReleased\fR | essage is received at an end node of a signalling connection, the following actions are performed on the connection section: .RT .LP 1) A \fIRelease Complete\fR | essage is sent on the connection section. .LP 2) The resources associated with the connection section are released, the SCCP user is informed that a release has occured by invoking the N\(hyDISCONNECT INDICATION primitive, and the local reference number is frozen. .LP 3) The inactivity control timers, T(ias) and T(iar), if still running, are stopped. .sp 1P .LP 3.4 \fIInactivity control\fR .sp 9p .RT .PP The purpose of the inactivity control is to recover from: .EF '% Fascicle\ VI.7\ \(em\ Rec.\ Q.714'' .OF '''Fascicle\ VI.7\ \(em\ Rec.\ Q.714 %' .RT .LP 1) loss of a \fIConnection Confirm\fR | essage during connections establishment, and .LP 2) the unsignalled termination of a connection section during data transfer, and .LP 3) a discrepancy in the connection data held at each end of a connection. .PP Two inactivity control timers, the receive inactivity control timer T(iar) and the send inactivity control timer T(ias), are required at each end of a connection section. The length of the receive inactivity timer must be longer than the length of the send inactivity timer. .PP When any message is sent on a connection section, the send inactivity control timer is reset. .PP When any message is sent on a connection section, the receive inactivity control timer is reset. .PP When the send inactivity timer, T(ias), expires, an \fIInactivity Test\fR | (IT) message is sent on the connection section. .PP The receiving SCCP checks the information contained in the IT message against the information held locally. If a discrepancy is detected, the following actions (Table\ 1/Q.714) are taken: .RT .PP When the receive inactivity control timer, T(iar), expires, the connection release procedure is initiated on a temporary connection section and an OA&M function is alerted for a permanent connection section. .PP As an alternative to inactivity control timers in the SCCP, there is also the possibility of supervising a signalling connection by a SCCP user function. .bp .RT .ce \fBH.T. [T1.714]\fR .ce TABLE\ 1/Q.714 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(84p) | cw(84p) . Discrepancy Action _ .T& lw(84p) | lw(84p) . Source reference number Release connection _ .T& lw(84p) | lw(84p) . Protocol class Release connection _ .T& lw(84p) | lw(84p) . { Sequencing/segmenting | ua\d\u)\d } Reset connection _ .T& lw(84p) | lw(84p) . Credit | ua\d\u)\d Reset connection .TE .LP \ua\d\u)\d Does not apply to class 2 connection. .nr PS 9 .RT .ad r \fBTable 1/Q.711 [T1.714], p.\fR .sp 1P .RT .ad b .RT .sp 2P .LP 3.5 \fIData transfer\fR .sp 1P .RT .sp 1P .LP 3.5.1 \fIGeneral\fR .sp 9p .RT .PP The purpose of data transfer is to provide the functions necessary to transfer user information on a temporary or permanent signalling connection. .RT .sp 1P .LP 3.5.1.1 \fIActions at the originating node\fR .sp 9p .RT .PP The SCCP user at the originating node requests transfer of user data on a signalling connection by invoking the N\(hyDATA REQUEST primitive. .PP The \fIData\fR | essage is then generated, which must be transferred on the connection section. If flow control procedures apply to the connection section, these procedures must be enacted before the message can be forwarded on the connection section. .RT .sp 1P .LP 3.5.1.2 \fIActions at the intermediate node\fR .sp 9p .RT .PP If a signalling connection consists of more than one connection section, then one or more intermediate nodes are involved in the transfer of \fIData\fR messages on the signalling connection. .PP When a valid \fIData\fR | essage is received on an incoming connection section at an intermediate node, the associated outgoing connection section is determined. The intermediate node then forwards the \fIData\fR message to the .PP associated outgoing connection section for transfer to the distant node. If flow control procedures apply to the connection sections, then the appropriate procedures must be enacted on both connection sections. On the incoming connection section, these procedures relate to the reception of a valid \fIData\fR message and on the outgoing connection section, the procedures control the flow of \fIData\fR messages on the connection section. .RT .sp 1P .LP 3.5.1.3 \fIActions at the destination node\fR .sp 9p .RT .PP When the destination node receives a valid \fIData\fR | essage, the SCCP user (i.e.,\ the Called Party Address) is notified by invoking the N\(hyDATA INDICATION primitive. If flow control procedures apply to the signalling connection, the flow control procedures relating to the reception of a valid \fIData\fR message are enacted. .bp .RT .sp 2P .LP 3.5.2 \fIFlow control\fR .sp 1P .RT .sp 1P .LP 3.5.2.1 \fIGeneral\fR .sp 9p .RT .PP The flow control procedures apply during data transfer only, and are used to control the flow of \fIData\fR | essages on each connection section. .PP The flow control procedures apply only to protocol class\ 3. .PP The reset procedure causes reinitialization of the flow control procedure. .PP The expedited data procedure is not affected by this flow control procedure. .RT .sp 1P .LP 3.5.2.2 \fISequence numbering\fR .sp 9p .RT .PP For protocol class 3, for each direction of transmission on a connection section, the \fIData\fR | essages are sequentially numbered. .PP The sequence numbering scheme of the \fIData\fR | essages is performed modulo\ 128 on a connection section. .PP Upon initialization or reinitialization of a connection section, message send sequence numbers, P(S), are assigned to \fIData\fR | essages on a connection section beginning with P(S) equal to\ 0. Each subsequent \fIData\fR message sequence number is obtained by incrementing the last assigned value by\ 1. The sequence numbering scheme assigns sequence numbers up to\ 127. .RT .sp 1P .LP 3.5.2.3 \fIFlow control window\fR .sp 9p .RT .PP A separate window is defined, for each direction of transmission, on a connection section in order to control the number of \fIData\fR messages .PP authorized for transfer on a connection section. The window is an ordered set of W\ consecutive message send sequence numbers associated with the \fIData\fR messages authorized for transfer on the connection section. .PP The lower window edge is the lowest sequence number in the window. .PP The sequence number of the first \fIData\fR | essage not authorized for transfer on the connection is the value of the lower window edge plus\ W. .PP The maximum window size is set during connection establishment for temporary connection sections. For permanent connection sections, the window size is fixed at establishment. The maximum size cannot exceed\ 127. .PP Negotiation procedures during connection establishment allow for the negotiation of the window size. .RT .sp 2P .LP 3.5.2.4 \fIFlow control procedures\fR .sp 1P .RT .sp 1P .LP 3.5.2.4.1 \fITransfer of Data messages\fR .sp 9p .RT .PP If flow control procedures apply to a connection section, then all \fIData\fR | essages on the connection section contain a send sequence number, P(S), and a receive sequence number, P(R). The procedure for determining the send sequence number to be used in a \fIData\fR message is described in \(sc\ 3.5.2.2. .PP The receive sequence number, P(R), is set equal to the value of the next send sequence number expected on the connection section and P(R) becomes the lower window edge of the receiving window. .PP An originating or intermediate node is authorized to transmit a \fIData\fR message if the message send sequence number of the message is within the sending window. That is, if P(S) is greater than or equal to the lower window edge and less than the lower window edge plus\ W. When the send sequence number of a \fIData\fR message is outside of the sending window, the node is not authorized to transmit the message. .RT .sp 1P .LP 3.5.2.4.2 \fITransfer of Data Acknowledgement messages\fR .sp 9p .RT .PP \fIData Acknowledgement\fR | essages may be sent when there are no \fIData\fR | essages to be transferred on a connection section .FS Further study is required to determine criterion to be used to decide when \fIData\fR \fIAcknowledgement\fR | essages are sent for cases other than the congestion situation described in this section. .FE . .bp .PP When a node transfers a \fIData Acknowledgement\fR | essage on a connection section, it is indicating that the node is ready to receive W\ \fIData\fR .PP messages within the window starting with the receive sequence number,\ P(R), found in the \fIData Acknowledgement\fR message. That is, P(R)\ is the next send sequence number expected at the remote node on the connection section. Furthermore, P(R) also becomes the lower window edge of the receiving window. .PP A \fIData Acknowledgement\fR | essage must be sent when a valid \fIData\fR | message, as per \(sc\ 3.5.2.4.3 on P(S) and P(R), is received and P(S) is equal to the upper edge of the receiving window and there are no \fIData\fR messages to be transferred on the connection section. Sending of \fIData Acknowledgement\fR messages before having reached the upper edge of the receiving window is also allowed during normal operation. .PP \fIData acknowledgement\fR | messages may also be sent by a node encountering congestion on a connection section as described below: .PP Assuming nodes X and Y are the two ends of a connection section, the following procedures apply. .PP When a node (Y) experiences congestion on a connection section, it informs the remote node\ (X) using the \fIData Acknowledgement\fR message with the credit set to zero. .PP Node (X) stops transferring \fIData\fR | essages on the connection section. .PP Node X updates the window on the connection section using the value of the receive sequence number,\ P(R), in the \fIData Acknowledgement\fR message. .PP Node X begins transfer of \fIData\fR | essage when it receives a \fIData\fR \fIAcknowledgement\fR | essage with a credit field greater than zero or when a \fIReset\fR message is received on a connection section for which a \fIData\fR \fIAcknowledgement\fR message with a credit field equal to zero had previously been received. .PP Node X updates the window on the connection using the credit value. The credit value in a \fIData Acknowledgement\fR message must either equal zero or equal the initial credit agreed to at connection establishment. .RT .sp 1P .LP 3.5.2.4.3 \fIReception of a Data or Data Acknowledgement message\fR .sp 9p .RT .PP When an intermediate or destination node receives a \fIData\fR message, it performs the following test on the send sequence number,\ P(S), contained in the \fIData\fR message: .RT .LP 1) If P(S) is the next send sequence number expected and is within the window, then the node accepts the \fIData\fR message and increments by one the value of the next sequence number expected on the connection section. .LP 2) If P(S) is not the next send sequence number expected, then the reset procedure is initiated on the connection section. .LP 3) If P(S) is not within the window, then this is considered a local procedure error and the connection reset procedure is initiated. .LP 4) If P(S) is not equal to 0 for the first \fIData\fR message received after initialization or reinitialization of the connection section, this is considered a local procedure error and the connection reset procedure is initiated. .PP The message receive sequence number, P(R), is included in \fIData\fR , and \fIData Acknowledgement\fR messages. When a node receives a \fIData\fR or \fIData\fR \fIAcknowledgement\fR message on a connection section, the value of the receive sequence number, P(R), implies that the remote node has accepted at least all \fIData\fR messages numbered up to and including P(R)\ \(em\ 1. That is, the next expected send sequence number at the remote node is P(R). The receive sequence number, P(R), contains information from the node sending the message, which authorizes the transfer of a limited number of \fIData\fR messages on the .LP connection section. When a node receives a \fIData\fR or \fIData Acknowledgement\fR message: .LP a) the receive sequence number, P(R), contained in the message becomes the lower window edge of the sending window: .LP 1) if the value of P(R) is greater than or equal to the last P(R) received by the node on that connection section, and also, .LP 2) if the value of the received P(R) is less than or equal to the P(S) of the next \fIData\fR message to be transferred on that connection section; .LP b) the node initiates the reset procedure on the connection section if the receive sequence number, P(R), does not meet conditions\ 1) and\ 2). .bp .sp 1P .LP 3.5.3 \fISegmenting and reassembly\fR .sp 9p .RT .PP During the data transfer phase, the N\(hyDATA REQUEST primitive is used to request transfer of octet\(hyaligned data (NSDUs) on a signalling connection. NSDUs longer than 255\ octets must be segmented before insertion into the \*Qdata\*U field of a \fIData\fR message. .PP The more\(hydata indicator (M\(hybit) is used to reassemble a NSDU that has been segmented for conveyance in multiple \fIData\fR messages. The M\(hybit is set to\ 1 in all \fIData\fR messages except the last message whose data field relates to a particular NSDU. In this way, the SCCP can reassemble the NSDU by combining the data fields of all \fIData\fR messages with the M\(hybit set to\ 1 with the following \fIData\fR message with the M\(hybit set to\ 0. The NSDU is then delivered to the SCCP user using the N\(hyDATA INDICATION. \fIData\fR messages in which the M\(hybit is set to\ 1 do not necessarily have the maximum length. .PP Segmentation and reassembly are not required if the length of the NSDU is less than or equal to 255\ octets. .RT .sp 2P .LP 3.6 \fIExpedited data transfer\fR .sp 1P .RT .sp 1P .LP 3.6.1 \fIGeneral\fR .sp 9p .RT .PP The expedited data procedure applies only during the data transfer phase and is applicable to protocol class\ 3. .PP For the case of expedited data transfer, each message contains one NSDU, and no segmenting and reassembly is provided. .PP If an \fIExpedited Data\fR or \fIExpedited Data Acknowledgement\fR message is lost, then subsequent \fIExpedited Data\fR messages cannot be forwarded on the connection section. .RT .sp 1P .LP 3.6.2 \fIActions at the originating node\fR .sp 9p .RT .PP The expedited data transfer procedure is initiated by the user of the SCCP using the N\(hyEXPEDITED\(hyDATA REQUEST primitive, which contains up to 32\ octets of user data. .PP When the SCCP user invokes the N\(hyEXPEDITED\(hyDATA REQUEST primitive, an \fIExpedited Data\fR message with up to 32\ octets of user data is transferred on the connection section once \fIall\fR previous \fIExpedited Data\fR messages for the connection section have been acknowledged. .RT .sp 1P .LP 3.6.3 \fIActions at intermediate node\fR .sp 9p .RT .PP Upon receiving a valid \fIExpedited Data\fR | essage, an intermediate node confirms this message by transferring an \fIExpedited Data Acknowledgement\fR message on the incoming connection section. Withholding of the \fIExpedited Data\fR \fIAcknowledgement\fR message is a means of providing flow control of \fIExpedited\fR \fIData\fR messages. .PP If a node receives another \fIExpedited Data\fR | essage on the incoming connection section before sending the \fIExpedited Data Acknowledgement\fR message, then the node will discard the subsequent message and reset the incoming connection section. .PP The intermediate node determines the associated outgoing connection section. An \fIExpedited Data\fR message is then transferred on the associated outgoing connection section, once \fIall\fR previous \fIExpedited Data\fR messages on that connection section have been acknowledged. .PP The \fIExpedited Data Acknowledgement\fR | essage must be sent before acknowledging subsequent \fIData\fR or \fIExpedited Data\fR messages received on the incoming connection section. .RT .sp 1P .LP 3.6.4 \fIActions at destination node\fR .sp 9p .RT .PP The destination node of the connection section confirms a valid \fIExpedited Data\fR | essage by transferring an \fIExpedited Data Acknowledgement\fR message on the connection section. Withholding of the \fIExpedited Data\fR \fIAcknowledgement\fR message is a means of providing flow control of \fIExpedited\fR \fIData\fR messages. .bp .PP If a node receives another \fIExpedited Data\fR | essage on a connection section before sending the \fIExpedited Data Acknowledgement\fR message, then the node will discard the subsequent message and reset the connection section. .PP The destination node then invokes the N\(hyEXPEDITED DATA INDICATION primitive. .PP The N\(hyEXPEDITED\(hyDATA INDICATION must be issued to the SCCP user at destination node before N\(hyDATA or N\(hyEXPEDITED\(hyDATA indications resulting from any subsequently issued N\(hyDATA or N\(hyEXPEDITED\(hyDATA requests at the originating node of that signalling connection. The initiation of the \fIExpedited Data\fR \fIAcknowledgement\fR message is implementation dependent. .RT .sp 2P .LP 3.7 \fIReset\fR .sp 1P .RT .sp 1P .LP 3.7.1 \fIGeneral\fR .sp 9p .RT .PP The purpose of the reset procedure is to reinitialize a connection section. It is applicable only to protocol class\ 3. It is noted that the time sequence of the primitives in the reset procedure may be varied as long as it is consistent with Recommendation\ X.213. .PP For a connection reset initiated by the SCCP, Data or Expedited Data messages should not be transferred on the connection section prior to the completion of the reset procedure. .RT .sp 2P .LP 3.7.2 \fIAction at the initiating node\fR .sp 1P .RT .sp 1P .LP 3.7.2.1 \fIInitial actions\fR .sp 9p .RT .PP When a connection reset is initiated, by the SCCP user invoking a N\(hyRESET REQUEST primitive or by the node itself, the following actions are performed at the initiating node: .RT .LP 1) A \fIReset Request\fR | essage is transferred on the connection section. .LP 2) The send sequence number, P(S), for the next \fIData\fR message is set to\ 0. The lower window edge is set to\ 0. The window size is reset to the initial credit value. .LP 3) The SCCP user is informed that a reset has taken place by: .LP \(em invoking the N\(hyRESET INDICATION primitive if the reset is network originated. .LP 4) The reset timer T (reset) is started. .sp 1P .LP 3.7.2.2 \fISubsequent actions\fR .sp 9p .RT .PP The following actions are performed at the initiating node on a connection section for which a \fIReset Request\fR message has been previously transferred: .RT .LP 1) When a \fIData\fR , \fIData Acknowledgement\fR , \fIExpedited Data\fR , or \fIExpedited Data Acknowledgement\fR message is received, the message is discarded. When an N\(hyDATA REQUEST or N\(hyEXPEDITED DATA REQUEST primitive is received, the primitive is discarded or stored up to the completion of the reset procedure. The choice between these two is implementation dependent. .LP 2) When the reset timer expires, the connection release procedure is initiated on a temporary connection section and maintenance functions are alerted for a permanent connection section. .LP 3) When a \fIReset Confirm\fR | r a \fIReset Request\fR | essage is received on the connection section, the reset is completed provided the SCCP has previously received an N\(hyRESET REQUEST or RESPONSE primitive from the SCCP user and, therefore, data .LP transfer is resumed and the timer T(reset) is stopped. The SCCP user is informed that the reset is completed by invoking the N\(hyRESET CONFIRMATION primitive. .LP 4) When a \fIReleased\fR message is received on a temporary connection section, the release procedure is initiated and the timer, T\ (reset), is stopped. .bp .sp 2P .LP 3.7.3 \fIActions at the intermediate node\fR .sp 1P .RT .sp 1P .LP 3.7.3.1 \fIInitial actions\fR .sp 9p .RT .PP The connection reset procedure is initiated at the intermediate node either by the SCCP at the node itself or by the reception of a \fIReset\fR \fIRequest\fR message. .PP When a \fIReset Request\fR | essage is received on a connection section, the following actions take place: .RT .LP 1) A \fIReset Confirm\fR | essage is transferred on the connection section. .LP 2) A \fIReset Request\fR | essage is transferred on the associated connection section; the reason for reset is identical to the reason in the \fIReset Request\fR message. .LP 3) On both the connection section and the associated connection section, the send sequence number, P(S), for the next \fIData\fR message to be transmitted is set to\ 0 and the lower window edge is set to\ 0. The window size is reset to the initial credit value on both connection sections. .LP 4) The data transfer procedure is initiated on the connection section. .LP 5) The reset timer, T (reset), is started on the associated connection section. .PP When the connection reset procedure is initiated by the SCCP at the intermediate node, the following actions take place on both of the connection sections: .LP 1) A \fIReset Request\fR | essage is transferred. .LP 2) The send sequence number, P(S), for the next \fIData\fR | essage is set to\ 0. The lower window edge is set to\ 0. The window size is reset to the initial credit value. .LP 3) The reset timer\ T (reset) is started. .sp 1P .LP 3.7.3.2 \fISubsequent actions\fR .sp 9p .RT .PP If the connection reset was initiated by reception of a \fIReset\fR \fIRequest\fR | message on a connection section, then the following actions are performed after initial actions are completed: .RT .LP 1) When a \fIData\fR , \fIData Acknowledgement\fR , \fIExpedited Data\fR , \fIExpedited Data Acknowledgement\fR message is received on the associated connection section, the message is discarded. .LP 2) When the reset timer expires on the associated connection section, the connection release procedure is initiated on both temporary connection sections and the maintenance function is alerted on an associated permanent connection section. .LP 3) When a \fIReleased\fR | essage is received on a temporary connection section, the connection release procedure is initiated on both connection sections and the timer, T (reset), is stopped. .LP 4) When a \fIReset Confirm\fR | r \fIReset Request\fR | essage is received on the associated connection section, the data transfer procedure is resumed and the timer, T (reset), is stopped. .PP If the connection reset was initiated by the SCCP at the intermediate node, then the following actions are performed once the initial actions are completed: .LP 1) When a \fIData\fR , \fIData Acknowledgement\fR , \fIExpedited Data\fR , or \fIExpedited Data Acknowledgement\fR message is received on either connection section, the message is discarded. .LP 2) When the reset timer expires on a temporary connection section, the connection release procedure is initiated on both connection sections, and on a permanent connection section a maintenance function is alerted. .LP 3) When a \fIReleased\fR | essage is received on a temporary connection section, the connection release procedure is initiated on both connection sections and the timer, T\ (reset), is stopped . .LP 4) When a \fIReset Confirm\fR | r \fIReset Request\fR | essage is received on a connection section, data transfer is resumed on that connection and the timer, T\ (reset), is stopped. .bp .sp 1P .LP 3.7.4 \fIActions at the destination node\fR .sp 9p .RT .PP When a \fIReset Request\fR | essage is received at a node, the following actions are performed on the connection section: .RT .LP 1) The send sequence number, P(S), for the next \fIData\fR | essage is set to\ 0, the lower window edge is set to\ 0. The window size is reset to the initial credit value. .LP 2) The SCCP user is informed that a reset has occurred by invoking the N\(hyRESET INDICATION primitive. .LP 3) A \fIReset Confirm\fR | essage is transferred on the connection section after an N\(hyRESET RESPONSE or REQUEST primitive is invoked by the user. .LP 4) An N\(hyRESET CONFIRMATION primitive is invoked to inform the SCCP user that the reset is completed and the data transfer can be resumed. .sp 1P .LP 3.7.5 \fIHandling of messages during the reset procedures\fR .sp 9p .RT .PP Once the reset procedure is initiated, the following actions are taken with respect to \fIData\fR messages: .RT .LP \(em those that have been transmitted, but for which an acknowledgement has not been received, are discarded, and .LP \(em those that have not been transmitted, but are contained in an M\(hybit sequence for which some \fIData\fR messages have been transmitted, are discarded, .LP \(em those \fIData\fR | essages that have been received, but which do not constitute an entire M\(hybit sequence, are discarded. .sp 2P .LP 3.8 \fIRestart\fR .sp 1P .RT .sp 1P .LP 3.8.1 \fIGeneral\fR .sp 9p .RT .PP The purpose of the restart procedure is to provide a recovery mechanism for signalling connection sections in the event of a node failure. .RT .sp 2P .LP 3.8.2 \fIActions at the recovered node\fR .sp 1P .RT .sp 1P .LP 3.8.2.1 \fIInitial actions\fR .sp 9p .RT .PP When a node recovers from its failure, the following actions are performed: .RT .LP 1) A guard timer, T(guard) .FS The guard timer must be large enough, so that all the non\(hyfailed far end nodes can detect the failure and .LP can safely release the affected temporary signalling connection sections. This implies T(guard) | | (iar) | | (rel). .FE , is started. .LP 2) If the recovered node has knowledge about the local reference numbers in use before failure, then the normal procedures for temporary signalling connections are resumed with the assumption that the local reference numbers which were in use before the node failure are not assigned at least during T(guard). .LP 3) An OA&M function is informed for the re\(hyestablishment of permanent signalling connections. .sp 1P .LP 3.8.2.2 \fISubsequent actions\fR .sp 9p .RT .PP The following actions are performed at the recovered node, on every temporary signalling connection section if the node does not know the local reference numbers in use before failure, or only on the temporary signalling connection sections in operation before failure if the node has such knowledge: .RT .LP a) Before the guard timer, T(guard), expires: .LP 1) When a \fIReleased\fR | message is received with both source and destination local reference numbers, a \fIRelease Complete\fR message, with reversed local reference numbers, is returned to the originating point code. .LP 2) Any other connection\(hyoriented messages received are discarded. .LP b) When the guard timer, T(guard), expires, normal procedures are resumed. .bp .sp 1P .LP 3.8.3 \fIActions at the non\(hyfailed far end node\fR .sp 9p .RT .PP The inactivity control procedure, described in \(sc\ 3.4, is used by the non\(hyfailed far end node to recover from the unsignalled termination of a connection section during data transfer. .RT .sp 1P .LP 3.9 \fIPermanent signalling connections\fR .sp 9p .RT .PP Permanent signalling connections are set up administratively and connection establishment procedures and connection release procedures are not initiated by the SCCP user. .PP Permanent signalling connections are realized using one or more connection sections. .PP A permanent signalling connection is either in the data transfer phase or the reset phase. Therefore, all procedures relating to the data transfer phase for connection\(hyoriented protocol classes and the reset procedures are applicable to permanent signalling connections. .RT .sp 2P .LP 3.10 \fIAbnormalities\fR .sp 1P .RT .sp 1P .LP 3.10.1 \fIGeneral\fR .sp 9p .RT .PP Errors can be classified into the three categories listed below. Examples of each category are included for clarification: .RT .LP 1) \fISyntax errors\fR \ \(em\ This type of error occurs when a node receives a message that does not conform to the format specifications of the SCCP. Examples of syntax errors are: .LP \(em reception of message with an invalid message type code, and .LP \(em reception of a message with an unassigned local reference number. .LP 2) \fILogical errors\fR \ \(em\ This type of error occurs when a node receives a message that is not an acceptable input to the current state of the connection section, or whose value of P(S) or P(R) is invalid. Examples of logical errors are: .LP \(em reception of an acknowledgement message when the corresponding request message has not been sent, .LP \(em reception of a \fIData\fR | essage whose data field length exceeds the maximum data field permitted on the connection section, .LP \(em reception of a second \fIExpedited Data\fR | essage before an \fIExpedited Data Acknowledgement\fR message has been sent, and .LP \(em reception of message whose value of P(R) is not greater than or equal to the last P(R) received and is not less than or equal to the next value of P(S) to be transmitted. .LP 3) \fITransmission errors\fR \ \(em\ This type of error occurs when a message is lost or delayed. Examples of transmission errors are: .LP \(em expiration of a timer before reception of the appropriate acknowledgement message. .sp 1P .LP 3.10.2 \fIAction tables\fR .sp 9p .RT .PP The action tables found in Recommendation\ Q.714, Annex\ B, include information, in addition to that found in the text of Recommendation\ Q.714, regarding the actions to be performed upon receipt of a message. In particular, these tables are helpful in determining the actions to be performed upon receipt of a message resulting in a logical error. .RT .sp 1P .LP 3.10.3 \fIActions upon the reception of an ERR message\fR .sp 9p .RT .PP Upon the reception of a \fIProtocol Data Unit Error\fR | (ERR) message at a node, the following actions are performed on the connection section for error causes other than \*Qservice class mismatch\*U: .RT .LP 1) The resources associated with the connection are released. .LP 2) The local reference number is frozen (see \(sc\ 3.3.2). .PP Upon the reception of a \fIProtocol Data Unit Error\fR | ERR) message at a node with the error cause \*Qservice class mismatch\*U, the connection release procedure is initiated by the SCCP at that node (see \(sc\ 3.3). .bp .sp 2P .LP \fB4\fR \fBConnectionless procedures\fR .sp 1P .RT .PP The connectionless procedures allow a user of the SCCP to request transfer of up to X\ octets of user data without first requesting establishment of a signalling connection. .PP The N\(hyUNITDATA REQUEST and INDICATION primitives are used by the user of the SCCP to request transfer of user data by the SCCP and for the SCCP to indicate delivery of user data to the destination user. Parameters associated with the N\(hyUNITDATA REQUEST primitive must contain all information necessary for the SCCP to deliver the user data to the destination. .PP Transfer of the user data is accomplished by including the user data in \fIUnitdata\fR messages. .PP The user of the SCCP should ensure that the total length of the user data and the SCCP address information does not exceed the total permissible length of the SCCP Unitdata message. .PP If user data of excessive length is presented by the user of the SCCP, the SCCP should not transmit a part of it to the remote user of the SCCP. .PP Whether or not the local SCCP user should be informed by the SCCP is implementation dependent. .PP When the user of the SCCP requests transfer of user data by issuing a N\(hyUNITDATA REQUEST primitive, there are two classes of service that can be provided by the SCCP, protocol classes\ 0 and\ 1. These protocol classes are distinguished by their message sequencing characteristics. .PP When the user of the SCCP requests transfer of several messages by issuing multiple N\(hyUNITDATA REQUEST primitives, the probability of these messages being received in sequence at the \*QCalled address\*U depends on the protocol class designated in the request primitives. For protocol class\ 0 the sequence control parameter is not included in the N\(hyUNITDATA REQUEST primitive and the SCCP may generate a different SLS for each of these messages. For protocol class\ 1 the sequence control parameter is included in the N\(hyUNITDATA REQUEST primitive and, if the parameter is the same in each request primitive, then the SCCP will generate the same SLS for these messages. .PP The Message Transfer Part retains message sequencing for those messages with the same SLS field. The Signalling Connection Control Part relies on the services of the MTP for transfer of SCCP messages. Based on the characteristics of the MTP, the protocol class\ 1 service may be used in such a way that it provides a quality of service that has a lower probability of out\(hyof\(hysequence messages than that provided by protocol class\ 0. .RT .sp 1P .LP 4.1 \fIData transfer\fR .sp 9p .RT .PP The N\(hyUNITDATA REQUEST primitive is invoked by the SCCP user at an originating node to request connectionless data transfer service. The connectionless data transfer service is also used to transport SCCP management messages, which are transferred in the \*Qdata\*U field of \fIUnitdata\fR messages. .PP The \fIUnitdata\fR | message is then transferred, using SCCP and MTP routing functions, to the \*QCalled address\*U indicated in the UNITDATA REQUEST primitive. .PP SCCP routing and relaying functions may be required at intermediate nodes, since complete translation and routing tables for all addresses are not required at every node. .PP When the \fIUnitdata\fR | essage cannot be transferred to its destination, the message return function is initiated. .PP The SCCP uses the services of the MTP and the MTP may, under severe network conditions, discard messages. Therefore, the user of the SCCP may not always be informed of non\(hydelivery of user data. The MTP notifies the SCCP of unavailable signalling points using the MTP\(hySTOP INDICATION and of congested signalling points using the MTP\(hyPAUSE INDICATION. The SCCP then informs its users. .PP When a \fIUnitdata\fR | essage is received at the destination node, a N\(hyUNITDATA INDICATION primitive is invoked except for the SCCP management messages. The SCCP management (SCMG) messages are passed to the SCMG entity instead. .bp .RT .sp 1P .LP 4.2 \fIMessage return\fR .sp 9p .RT .PP The purpose of message return is to discard or return messages which encounter routing failure and cannot be delivered to their final destination. .PP The message return procedure is initiated if SCCP routing is unable to transfer a \fIUnitdata\fR or \fIUnitdata Service\fR message. The procedure may be .PP initiated, for example, as a result of insufficient translation information or the inaccessibility of a subsystem or point code. Specific reasons are enumerated in \(sc\ 2.3. .RT .LP a) If the message is a \fIUnitdata\fR | essage, and .LP \(em the option field is set to return message on error, then a \fIUnitdata Service\fR | essage is transferred to the \*Qcalling party address\*U. (If the message is originated locally, then a N\(hyNOTICE INDICATION primitive is invoked.) .LP \(em the option field is not set to return on error, then the message is discarded. .LP b) If the undeliverable message is a \fIUnitdata Service\fR | essage, it is discarded. .PP The user \*Qdata\*U field of the \fIUnitdata\fR | essage and the reason for return are included in the \fIUnitdata Service\fR message. .PP When a \fIUnitdata Service\fR message is received at the destination node, a N\(hyNOTICE INDICATION primitive is invoked. .RT .sp 1P .LP 4.3 \fISyntax error\fR .sp 9p .RT .PP This type of error occurs when a node receives a message that does not conform to the format specifications of the SCCP. Examples of syntax errors are: .RT .LP \(em unreasonable pointer value (e.g., points beyond the end of the message); .LP \(em mismatch between message type and protocol class parameters; and .LP \(em inconsistent address indicator and address contents. .PP When syntax error is detected for a connectionless message, the message is discarded. Checking for syntax errors beyond the processing required for the SCCP connectionless message routing is not mandatory. .sp 2P .LP \fB5\fR \fBSCCP management procedures\fR .sp 1P .RT .sp 1P .LP 5.1 \fIGeneral\fR .sp 9p .RT .PP The purpose of SCCP management is to provide procedures to maintain network performance by rerouting or throttling traffic in the event of failure or congestion in the network. .PP Although SCCP management has its own subsystem number, the procedures in this section does not apply to it. .PP SCCP management is organized into two subfunctions: signalling point status management and subsystem status management. Signalling point status management and subsystem status management allow SCCP management to use information concerning the accessibility of signalling points and subsystems, respectively, to permit the network to adjust to failure, recovery and congestion. .PP SCCP management procedures rely on: .RT .LP 1) failure, recovery, and congestion information provided in the MTP\(hyPAUSE INDICATION, MTP\(hyRESUME INDICATION and MTP\(hySTATUS INDICATION primitives; and .LP Subsystem congestion control is for further study. .FE 2) subsystem failure, recovery and congestion information received in SCCP management messages . .PP SCCP management information is currently defined to be transferred using SCCP connectionless service with no return on error requested. Formats of these messages appear in Recommendation\ Q.713. .bp .PP The information pertaining to both single and replicated nodes or subsystems is used for SCCP management purposes. This allows \*Qcalled party addresses\*U that are specified in the form of a global title to be translated to different point codes and/or subsystem numbers depending on network or subsystem status. .PP Replicated nodes or subsystems may relate to their replicates in one of several ways. (\*QReplicate\*U is a term meaning one of a set of \*Qmultiple copies\*U. A node of subsystem which is not replicated is termed \*Qsolitary\*U.) .PP One mode uses a replicate in a dominant role. Traffic is split among several nodes/subsystems. Under normal conditions, each portion of the traffic is routed to a preferred, or \*Qprimary\*U, node/subsystem. When the primary node/subsystem is inaccessible, this traffic is routed to a \*Qbackup\*U node/subsystem . When the primary node/subsystem recovers, it reassumes its normal traffic load. .PP A second mode uses a replicate in a replacement role. Consider two replicates, A and B, which are \*Qalternatives\*U. When A becomes inaccessible, its traffic is routed to\ B; but when A recovers, the traffic is not moved back to\ A. It is only when B becomes inaccessible that traffic is shifted back to\ A. In addition, other modes are possible. .PP The current SCCP management procedures are designed to manage solitary nodes/subsystems, and replicated nodes/subsystems which operate in a dominant mode and for which any given primary node/subsystem has only one backup (i.e.,\ duplicated nodes/subsystems). Management procedures for nodes/subsystems which operate in a mode other than the dominant mode and which have more than one backup are for further study. .PP SCCP management procedures utilize the concept of a \*Qconcerned\*U subsystem or signalling point. In this context, a \*Qconcerned\*U entity means an entity with an immediate need to be informed of a particular signalling point/subsystem status change, independently of whether SCCP communication is in progress between the \*Qconcerned\*U entity and the affected entity with the status change .FS Further explicit definition of \*Qconcerned\*U subsystems or signalling points would be network/architecture/application dependent. .FE . .PP In some situations, the number of concerned subsystem or signalling points for a given subsystem may be zero. In this case, when the subsystem fails, or becomes unavailable, no broadcast of the subsystem prohibited message is performed. Instead, the response method is used to return the subsystem prohibited message. Similarly, no broadcast of the subsystem allowed message is performed for that given subsystem when it recovers. The response method is again used to return a subsystem allowed message in reply to a subsystem status test. .PP The signalling point prohibited, signalling point allowed and signalling point congested procedures, specified in \(sc\(sc\ 5.2.2, 5.2.3 and\ 5.2.4 respectively, deal with the accessibility of a signalling point. .PP The subsystem prohibited and subsystem allowed procedures, detailed in \(sc\(sc\ 5.3.2 and\ 5.3.3 respectively, deal with the accessibility of a subsystem. .PP An audit procedure to ensure that necessary subsystem management information is always available is specified in the subsystem status test procedure in \(sc\ 5.3.4. .PP A subsystem may request to go out of service using the coordinated state change control procedure specified in \(sc\ 5.3.5. .PP Local subsystems are informed of any related subsystem status by the local broadcast procedure specified in \(sc\ 5.3.6. .PP Concerned signalling points are informed of any related subsystem status by the broadcast procedure specified in \(sc\ 5.3.7. .RT .sp 2P .LP 5.2 \fISignalling point status management\fR .sp 1P .RT .sp 1P .LP 5.2.1 \fIGeneral\fR .sp 9p .RT .PP Signalling point status management updates translation and status based on the information of network failure, recovery, or congestion provided by the MTP\(hyPAUSE INDICATION, MTP\(hyRESUME INDICATION, or MTP\(hySTATUS INDICATION primitives. This allows alternative routing to backup signalling points and/or backup subsystems. .bp .RT .sp 1P .LP 5.2.2 \fISignalling point prohibited\fR .sp 9p .RT .PP When SCCP management receives a MTP\(hyPAUSE INDICATION relating to a destination that become inaccessible, SCCP management: .RT .LP 1) marks the translation as appropriate: .LP \(em \*Qtranslate to backup node\*U if that signalling point has a backup; .LP \(em \*Qtranslate to backup subsystem\*U for each subsystem at that signalling point for which a backup subsystem exists. .LP 2) marks as \*Qprohibited\*U the status of that signalling point and of each subsystem at that signalling point. .LP 3) discontinues any subsystem status tests (\(sc\ 5.3.4) it may be conducting to any subsystems at that signalling point. .LP 4) initiates a local broadcast (\(sc 5.3.6) of \*QUser\(hyout\(hyof\(hyservice\*U information for each subsystem at that signalling point. .LP 5) initiates a local broadcast (\(sc 5.3.6) of \*Qsignalling point inaccessible\*U information for that signalling point. .sp 1P .LP 5.2.3 \fISignalling point allowed\fR .sp 9p .RT .PP When SCCP management receives a MTP\(hyRESUME INDICATION relating to a destination that becomes accessible, SCCP management: .RT .LP 1) resets the congestion level of that signalling point. .LP 2) marks the translation as appropriate: .LP \(em \*Qtranslate to primary node\*U if that signalling point has a backup. .LP 3) marks as \*Qallowed\*U the status of that signalling point. .LP 4) initiates the subsystem status test procedure (\(sc\ 5.3.4) with affected subsystems at that signalling point. .LP 5) initiates a local broadcast (\(sc\ 5.3.6) of \*Qsignalling point inaccessible\*U information for that signalling point. .sp 1P .LP 5.2.4 \fISignalling point congested\fR .sp 9p .RT .PP When SCCP management receives a MTP\(hystatus indication relating to signalling network congestion to a signalling point, SCCP management: .RT .LP 1) updates that signalling point status to reflect the congestion. .LP 2) initiates a local broadcast (\(sc\ 5.3.6) of \*Qsignalling point congested\*U information for that signalling point. .sp 2P .LP 5.3 \fISubsystem status management\fR .sp 1P .RT .sp 1P .LP 5.3.1 \fIGeneral\fR .sp 9p .RT .PP Subsystem status management updates translation and status based on the information of failure, withdrawal, congestion , and recovery of .PP subsystems. This allows alternative routing to backup systems, if appropriate. Local users are informed of the status of their backup subsystems. .RT .sp 2P .LP 5.3.2 \fISubsystem prohibited\fR .sp 1P .RT .sp 1P .LP 5.3.2.1 \fIReceipt of messages for a prohibited subsystem\fR .sp 9p .RT .PP If SCCP routing control receives a message, whether originated locally or not, for a prohibited local system, SCCP routing control invokes subsystem prohibited control. A \fISubsystem\(hyProhibited\fR message is sent to the originating signalling point if the originating subsystem is not local (the OPC is a parameter in the MTP\(hyTRANSFER INDICATION primitive). The action, if any, to be taken, if the originating subsystem is local, is for further study. .bp .RT .sp 1P .LP 5.3.2.2 \fIReceipt of Subsystem\(hyProhibited message or N\(hySTATE REQUEST\fR \fIprimitive or local user failed\fR .sp 9p .RT .PP Under one of the following conditions: .RT .LP a) SCCP management receives a \fISubsystem\(hyProhibited\fR | message about a subsystem marked allowed, or .LP b) a N\(hySTATE REQUEST primitive with \*QUser\(hyout\(hyof\(hyservice\*U information is invoked by a subsystem marked allowed, or .LP c) SCCP management detects that a local subsystem has failed, .LP then SCCP management does the following: .LP 1) marks the translation as appropriate: .LP \(em \*Qtranslate to backup subsystem\*U if a backup subsystem exists for the prohibited subsystem. .LP 2) marks as \*Qprohibited\*U the status of that subsystem. .LP 3) initiates a local broadcast (\(sc\ 5.3.6) of \*QUser\(hyout\(hyof\(hyservice\*U information for the prohibited subsystem. .LP 4) initiates the subsystem status test procedure (\(sc\ 5.3.4) if the prohibited subsystem is not local. .LP 5) forwards the information throughout the network by initiating a broadcast (\(sc\ 5.3.7) of \fISubsystem\(hyProhibited\fR messages to concerned signalling points. .LP 6) cancels \*Qignore subsystem status test\*U and the associated timer if they are in progress and if the newly prohibited subsystem resides at the local node. .sp 1P .LP 5.3.3 \fISubsystem allowed\fR .sp 9p .RT .PP Under one of the following conditions: .RT .LP a) SCCP management receives a \fISubsystem\(hyAllowed\fR | message about a subsystem marked prohibited, or .LP b) a N\(hySTATE REQUEST primitive with \*QUser\(hyin\(hyService\*U information is invoked by a subsystem marked prohibited, .LP then SCCP management does the following: .LP 1) marks the translation as appropriate: .LP \(em \*Qtranslate to primary subsystem\*U if that subsystem is duplicated and the primary subsystem is allowed; .LP \(em \*Qtranslate to backup subsystem\*U if that subsystem is duplicated and the primary subsystem is prohibited. .LP 2) marks as \*Qallowed\*U the status of that subsystem. .LP 3) initiates as a local broadcast (\(sc\ 5.3.6) of \*QUser\(hyin\(hyservice\*U information for the allowed subsystem. .LP 4) discontinues the subsystem status test relating to that subsystem if such a test was in progress. .LP 5) forwards the information throughout the network by initiating a broadcast (\(sc\ 5.3.7) of \fISubsystem\(hyAllowed\fR | messages to concerned signalling points. .sp 2P .LP 5.3.4 \fISubsystem status test\fR .sp 1P .RT .sp 1P .LP 5.3.4.1 \fIGeneral\fR .sp 9p .RT .PP The subsystem status test procedure is an audit procedure to verify the status of a subsystem marked prohibited. .RT .sp 1P .LP 5.3.4.2 \fIActions at the initiating node\fR .sp 9p .RT .PP A subsystem status test is initiated when: .RT .LP a) a \fISubsystem\(hyProhibited\fR | message is received (\(sc\ 5.3.2.2), or .LP b) a MTP\(hyRESUME INDICATION primitive for a previously inaccessible signalling point is invoked (\(sc\ 5.2.3). .bp .PP A subsystem status test associated with a failed subsystem is commenced by starting a timer (stat.info) and marking a test in progress. No further actions are taken until the timer expires. .PP Upon expiration of the timer, a \fISubsystem\(hyStatus\(hyTest\fR | message is sent to SCCP management at the node of the failed subsystem and the timer is reset. .PP The cycle continues until the test is terminated by another SCCP management function at that node. Termination of the test causes the timer and the test mark to be cancelled. .RT .sp 1P .LP 5.3.4.3 \fIActions at the receiving node\fR .sp 9p .RT .PP When SCCP management receives a \fISubsystem\(hyStatus\(hyTest\fR | message and there is no \*Qignore subsystem status test\*U in progress, it checks the status of the named subsystem. If the subsystem is allowed, a \fISubsystem\(hyAllowed\fR message is sent to the SCCP management at the node conducting the test. If the subsystem is prohibited, no reply is sent. .RT .sp 2P .LP 5.3.5 \fICoordinated state change\fR .sp 1P .RT .sp 1P .LP 5.3.5.1 \fIGeneral\fR .sp 9p .RT .PP A duplicated subsystem may be withdrawn from service without degrading the performance of the network by using the coordinated state change procedure described below when its backup is not local. The procedure, if any, to be specified in case the primary and the backup subsystems are co\(hylocated, is for further study. .RT .sp 1P .LP 5.3.5.2 \fIActions at the requesting node\fR .sp 9p .RT .PP When a duplicated subsystem wishes to go out of service, it invokes a N\(hyCOORD REQUEST primitive. SCCP management at that node sends a \fISubsystem\(hyOut\(hyof\(hyService\(hyRequest\fR message to the backup system, sets a timer (coord.chg) and marks the subsystem as \*Qwaiting for grant\*U. .PP Arrival of a \fISubsystem\(hyOut\(hyof\(hyService\(hyGrant\fR | message at the requesting SCCP management causes the timer (coord.chg) to be cancelled, the \*Qwaiting for grant\*U state to be cancelled, and a N\(hyCOORD CONFIRMATION primitive to be invoked to the requesting subsystem. \fISubsystem\(hyProhibited\fR messages are broadcast (\(sc\ 5.3.7) to concerned signalling points. .PP In addition, an \*Qignore subsystem status test\*U timer is started and the requesting subsystem is marked as \*Qignore subsystem status test\*U. Subsystem .PP status tests are ignored until the \*Qignore subsystem status test\*U timer expires or the marked subsystem invokes a N\(hySTATE REQUEST primitive with \*QUser\(hyout\(hyof\(hyservice\*U information. .PP If no \*Qwaiting for grant\*U is associated with the subsystem named in the \fISubsystem\(hyOut\(hyof\(hyService\(hyGrant\fR | message, the \fISubsystem\(hyOut\(hyof\(hyService\(hyGrant\fR | message is discarded and no further action is taken. .PP If the timer associated with the subsystem waiting for the grant expires before a \fISubsystem\(hyOut\(hyof\(hyService\(hyGrant\fR message is received, the \*Qwaiting for grant\*U is cancelled and the request is implicitly denied. .RT .sp 1P .LP 5.3.5.3 \fIActions at the requested node\fR .sp 9p .RT .LP The possibility of introducing an explicit Subsystem\(hyOut\(hyof\(hyService\(hyDenial message containing additional information and associated primitive is for further study. .FE .PP When the SCCP management at the node at which the backup subsystem is located receives the \fISubsystem\(hyOut\(hyof\(hyService\(hyRequest\fR message, it checks the status of local resources .FS Local resources are whatever is critical to this particular node, and are implementation dependent. .FE . If the SCCP has sufficient resources to assume the increased load, it invokes a N\(hyCOORD INDICATION primitive to the backup subsystem. If the SCCP does not have sufficient resources, no further action is taken . .RT .LP .sp 1 .bp .PP If the backup system has sufficient resources to allow its mate to go out of service, it informs SCCP management by invoking a N\(hyCOORD RESPONSE primitive. A \fISubsystem\(hyOut\(hyof\(hyService Grant\fR message is sent to SCCP management at the requesting node. If the backup subsystem does not have sufficient resources, no reply is returned . .RT .sp 2P .LP 5.3.6 \fILocal broadcast\fR .sp 1P .RT .sp 1P .LP 5.3.6.1 \fIGeneral\fR .sp 9p .RT .PP The local broadcast procedure provides a mechanism to inform local allowed concerned subsystems of any related subsystem/signalling point status information received. .RT .sp 1P .LP 5.3.6.2 \fIUser\(hyout\(hyof\(hyservice\fR .sp 9p .RT .PP These cases are applicable when the SCCP is used for routing between local subsystems. This function is implementation dependent. .FE A local broadcast of \*QUser\(hyout\(hyof\(hyservice\*U information is initiated when: .RT .LP a) a \fISubsystem\(hyProhibited\fR | message is received about a subsystem marked allowed (\(sc\ 5.3.2.2), or .LP b) an N\(hySTATE REQUEST primitive with \*QUser\(hyout\(hyof\(hyservice\*U information is invoked by a subsystem marked allowed (\(sc\ 5.3.2.2) , or .LP c) a local subsystem failure is detected by SCCP management (\(sc\ 5.3.2.2) , .LP d) an MTP\(hyPAUSE indication primitive is received (\(sc\ 5.2.2). .PP SCCP management then informs local allowed concerned SCCP subsystems about the subsystem status by invoking N\(hySTATE indication primitive with \*QUser\(hyout\(hyof\(hyservice\*U information. .sp 1P .LP 5.3.6.3 \fIUser\(hyin\(hyservice\fR .sp 9p .RT .PP A local broadcast of \*Qsubsystem\(hyin\(hyservice\*U information is initiated when: .RT .LP a) a \fISubsystem\(hyAllowed\fR | message is received about a subsystem marked prohibited (\(sc\ 5.3.3), or .LP b) an N\(hySTATE REQUEST primitive with \*QUser\(hyin\(hyservice\*U information is invoked by a subsystem marked prohibited (\(sc\ 5.3.3). .PP SCCP management then informs local allowed concerned SCCP subsystems, except the newly allowed one, about the subsystem status by invoking an N\(hySTATE indication primitive with \*QUser\(hyin\(hyservice\*U information. .sp 1P .LP 5.3.6.4 \fISignalling point inaccessible\fR .sp 9p .RT .PP A local broadcast of \*Qsignalling point inaccessible\*U information is initiated when an MTP\(hyRESUME primitive is received. SCCP management then .PP informs local allowed concerned SCCP subsystems about the signalling point status by invoking an N\(hyPCSTATE INDICATION primitive with \*Qsignalling point accessible\*U information. .RT .sp 1P .LP 5.3.6.5 \fISignalling point accessible\fR .sp 9p .RT .PP A local broadcast of \*Qsignalling point accessible\*U information is initiated when an MTP\(hyRESUME primitive is received. SCCP management then informs local allowed concerned SCCP subsystems about the signalling point status by invoking an N\(hyPCSTATE INDICATION primitive with \*Qsignalling point accessible\*U information. .RT .sp 1P .LP 5.3.6.6 \fISignalling point congested\fR .sp 9p .RT .PP A local broadcast of \*Qsignalling point congested\*U information is initiated when an MTP\(hySTATUS primitive is received. SCCP management then informs local allowed concerned SCCP subsystems about the signalling point status by invoking an N\(hyPCSTATE indication primitive with \*Qsignalling point congested (level)\*U information. .RT .LP .sp 1 .bp .sp 2P .LP 5.3.7 \fIBroadcast\fR .sp 1P .RT .sp 1P .LP 5.3.7.1 \fIGeneral\fR .sp 9p .RT .PP The broadcast procedure provides a mechanism that may be used to inform concerned signalling points of any related subsystem status change at local or adjacent signalling points. It is an optional procedure supplementary to that defined in \(sc\ 5.3.2.1. This procedure is suggested not to be used on a signalling point restart. This matter is for further study. .PP In some circumstances, the number of concerned signalling points is zero and no broadcast is performed. The action taken in this case is described in \(sc\ 5.1. .RT .sp 1P .LP 5.3.7.2 \fISubsystem prohibited\fR .sp 9p .RT .PP A broadcast of \fISubsystem\(hyProhibited\fR | messages is initiated when: .RT .LP a) a \fISubsystem Prohibited\fR | message is received about a subsystem presently marked allowed (\(sc\ 5.3.2.2), and the affected point code identified in the SSP message is the same as that of the informer signalling point, or .LP b) an N\(hySTATE REQUEST primitive with \*QUser\(hyout\(hyof\(hyservice\*U information is invoked by a subsystem marked allowed (\(sc\ 5.3.2.2), or .LP c) a local subsystem failure is detected by SCCP management \(sc\ 5.3.2.2), or .LP d) a \fISubsystem\(hyOut\(hyof\(hyService\(hyGrant\fR | message arrives for a subsystem marked \*Qwaiting for grant\*U (\(sc\ 5.3.5.2). .PP This broadcast permits SCCP management to inform all concerned signalling points, except the informer signalling point, about the subsystem status by \fISubsystem\(hyProhibited\fR messages. SCCP management does not broadcast if the point code of the prohibited subsystem is different from that of the informer signalling point which originates the \fISubsystem\(hyProhibited\fR message. .sp 1P .LP 5.3.7.3 \fISubsystem allowed\fR .sp 9p .RT .PP A broadcast of \fISubsystem\(hyAllowed\fR | messages is initiated when: .RT .LP a) a \fISubsystem\(hyAllowed\fR | message is received about a subsystem presently marked prohibited (\(sc\ 5.3.3), and the affected point code identified in the SSA message is the same as that of the informer signalling point, or .LP b) an N\(hySTATE REQUEST primitive with \*QUser\(hyin\(hyservice\*U information is invoked by a subsystem marked prohibited (\(sc\ 5.3.3). .PP This broadcast permits SCCP management to inform all concerned signalling points, except the informer signalling point, about the subsystem status by \fISubsystem\(hyAllowed\fR messages. SCCP management does not broadcast if the point code of the allowed subsystem is different from that of the informer signalling point which originates the \fISubsystem\(hyAllowed\fR message. .sp 1P .LP 5.4 \fISCMG restart\fR .sp 9p .RT .PP \fINote\fR \ \(em\ This section is for further study.) .PP On a signalling point restart, an indication is given to the SCCP by the MTP about the signalling points which are accessible after the restart actions. For each accessible, concerned signalling point, all subsystems there are marked allowed. The response method is used to determine the status of SCCP subsystems in those signalling points in the absence of the receipt of subsystem allowed, and subsystem prohibited messages, which may have been broadcast from them. .PP At the restarted signalling point, the status of its own subsystems are not broadcast to concerned signalling points. In this case, the response method is used to inform other nodes attempting to access prohibited subsystems at the restarted signalling points. .PP The SCCP management procedures specified in Recommendation\ Q.714, \(sc\ 5.2, describe the normal operation of management procedures, and do not describe signalling point restart actions. .bp .RT .ce 1000 ANNEX\ A .ce 0 .ce 1000 (to Recommendation Q.714) .sp 9p .RT .ce 0 .ce 1000 \fBState diagrams for the signalling connection\fR .sp 1P .RT .ce 0 .ce 1000 \fBcontrol part of Signalling System No. 7\fR .ce 0 .LP A.1 \fIIntroduction\fR .sp 1P .RT .PP This Annex contains the definitions for the symbols used and defines the states of the signalling point\ X/Y interface and the transitions between states in the normal case. .PP Annex B contains the full definition of actions, if any, to be taken on the receipt of messages by a signalling point. .RT .sp 1P .LP A.2 \fISymbol definition of the state diagrams at the message interface\fR \fIbetween two nodes (signalling points:\ X and\ Y)\fR (see Figures\ A\(hy1/Q.714 and A\(hy2/Q.714) .sp 9p .RT .LP .rs .sp 20P .ad r \fBFigure A\(hy1/Q.714, p.\fR .sp 1P .RT .ad b .RT .LP .rs .sp 14P .ad r \fBFigure A\(hy2/Q.714, p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP A.3 \fIOrder definition of the state diagrams\fR .sp 9p .RT .PP For the sake of clarity, the normal procedure at the interface is described in a number of small state diagrams. In order to describe the normal procedure fully, it is necessary to allocate a priority to the different figures and to relate a higher order diagram with a lower one. This has been done by the following means: .RT .LP \(em Figures A\(hy3/Q.714, A\(hy4/Q.714, A\(hy5/Q.714 and A\(hy6/Q.714 are arranged in order of priority, with Figure\ A\(hy3/Q.714 having the highest priority and subsequent figures having lower priority. Priority means that when a message belonging to a higher order diagram is transferred, that diagram is applicable and the lower order one is not. .LP \(em The relation with a state in a lower order diagram is given by including that state inside an ellipse in the higher order diagram. .LP \(em The message abbreviations are those defined in Recommendation\ Q.712. .LP .rs .sp 41P .ad r \fBFigure A\(hy3/Q.714, p.5\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 21P .ad r \fBFigure A\(hy4/Q.714, p.6\fR .sp 1P .RT .ad b .RT .LP .rs .sp 27P .ad r \fBFigure A\(hy5/Q.714, p.7\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 33P .ad r \fBFigure A\(hy6/Q.714, p.8\fR .sp 1P .RT .ad b .RT .LP .rs .sp 18P .sp 2P .LP \fBMONTAGE: ANNEXE B SUR LE RESTE DE CETTE PAGE\fR .sp 1P .RT .LP .bp