Internet Engineering Task Force INTERNET DRAFT Authors draft-toivanen-sccp-etheric-00.txt Harri Toivanen August 1998 Oy LM Ericsson Ab Expires: March 1999 Petteri Laamo Oy LM Ericsson Ab George Wayne Advanced Computer Communications Paul Harding-Jones Advanced Computer Communications Simplified Call Control Protocol - Etheric Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstract.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net, ftp.nis.garr.it (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo describes Simplified Call Control Protocol called Etheric between Signalling System 7 (SS7) controlled Public Switched Telephony Network (PSTN) and Network Access Server (NAS) created by Oy LM Ericsson Ab in co-operation with Advanced Computer Communications inc (ACC). 1. General Information 1.1 Introduction The Etheric 1.0 is the protocol used to control traffic between Public Switched Telephony Network GateWay (PSTN-GW, initially PSTN exchange) and Network Access Server (NAS) for call setup and release as well as for circuit maintenance. The signalling uses TCP/IP. 1.2 Terms and Abbreviations Direction backwards Messages which are sent against the call set-up direction Direction forwards Messages which are sent towards the call set-up direction. GS Group Switch. IP Internet Protocol. Node In this document, one end of the Etheric protocol, i.e. NAS or PSTN-GW. TCP Transmission Control Protocol. TDM Time Division Multiplexed line. 2. Function 2.1 General PSTN-GW IP-connection --------------------+ I +----------+ I I I I I IP- I I I terminal +------------------+ I I I I +----------+ I I I I TDM interfaces I I I +------+ I +--------+ I I I I I I I I I I I NAS 1 I I I I I I I I I GS +-----------+ +-+ I I I I I I I I I +--------+ I I I I I I I I I I I I I I I I +--------+ I I I I I I I I I I I NAS 2 I I I I I I I I I +-----------+ +-+ I I I I I I I I I +--------+ I I I I I I I I ... I I I I I I I I I I I I I I I I +--------+ I I I I I I I I I I I NAS n +-I I I I I I I I +-----------+ +-+ I I I I I I I I +--------+ I I I +------+ I I --------------------+ The figure above shows the configuration between PSTN-GW and NASs. The Etheric signalling protocol between the PSTN-GW and the NASs is of common channel type. IP-connection is used as the signaling path. TCP is used for reliable transfer of signalling information. As shown in the figure a group of NASs can be connected to the PSTN-GW. The PSTN-GW and NASs connected to the same IP-connection form an IP subnet where the PSTN-GW and each NAS have own IP-addresses. One NAS can be connected to one PSTN-GW only. Each NAS connected to the PSTN-GW with TDM interfaces is considered a 'signalling destination' identified by an IP address. While the Etheric signalling is transferred over the IP-connection the data traffic is transferred over the TDM interfaces. The Etheric protocol is a message oriented protocol based on ITU-T Q.767. The protocol identifies the timeslots in TDM interfaces used for traffic by means of a Circuit Identification Code (CIC). CICs are unique per signalling destination, i.e. per NAS. The CICs are numbered so that consecutive timeslots have consecutive CICs within a TDM interface. The Etheric protocol has procedures for automatic recovery from signalling TCP connection failures. The protocol also includes procedures for circuit management which allow the two ends of a signalling connection to align the circuit status after a manual action or an outage situation. 2.2 Security Considerations Because of nature of the Etheric protocol it must be secured either by separating IP-connection(s) containing signalling traffic from payload or encrypting IP-connection(s) below Etheric-level. This memo does not contain more about security matters. 2.3 Reliability Aspects For increased reliability two parallel IP-connections can be used by the Etheric signalling. The PSTN-GW and each NAS are connected to both IP-connections. The two signalling TCP connections are then set up over the two separate IP-connections. This is also the case when a pair of IP addresses is used to identify the signalling destination. 2.4 Message Format The signalling information is transferred by means of signalling messages. A message consists of length indicator and a variable length signalling information field (SIF) which carries the information between PSTN-GW and NAS. +-----+--------+ I I I I I Length I I SIF I Infor- I I I mation I I I I +-----+--------+ 2.4.1 LENGTH INFORMATION +---------------------+ I I I byte 0 I I I +---+-----------------+ I I I I F I byte1.B6-B0 I I I I +---+-----------------+ byte0 : not used, coded as 0 byte1.B6-B0: message length (number of bytes in the message, the length information part excluded) The F bit is reserved and MUST be set to 0. 2.4.2 SIGNALLING INFORMATION FIELD (SIF) +---------------------+ I I I Circuit I I Identification I I Code I I I +---------------------+ I I I Message type I I Code I I I +---------------------+ I I I Mandatory I I fixed part I I I +---------------------+ I I I Mandatory I I variable part I I I +---------------------+ 2.4.3 CIRCUIT IDENTIFICATION CODE (CIC) 8 7 6 5 4 3 2 1 +-------------------------------------------+ I I I CIC least significant bits I I I +---------------------+---------------------+ I I I I spare I CIC most I I I significant bits I I I I +---------------------+---------------------+ The spare bits MUST be set to 0. 2.4.4 MESSAGE TYPE CODE The message type code consists of a one octet field and is mandatory for all messages. The message type code uniquely defines the function and format of message. The allocation with reference to the appropriate descriptive section of this specification is found in section 2.5. 2.4.5 Formatting Principles Each message consists of a number of parameters listed and described in section 2.6. Each parameter has a name which is coded as a single octet (see section 2.6.2). The length of a parameter may be fixed or variable, and a length indicator of one octet may be included as described in section 2.6.1. 2.5 Message Type Codes The abbreviations used in this section are : F mandatory fixed length parameter V mandatory variable length parameter +---------------------------+-----------+-------------+ I I I I I message type I code I reference I I I I I +---------------------------+-----------+-------------+ I I I I I ADDRESS COMPLETE (ACM) I 0000 0110 I 2.5.1 I I I I I I ANSWER (ANM) I 0000 1001 I 2.5.2 I I I I I I BLOCKING (BLO) I 0001 0011 I 2.5.3 I I I I I I BLOCKING I 0001 0101 I 2.5.4 I I ACKNOWLEDGEMENT (BLA) I I I I I I I I CIRCUIT GROUP RESET (GRS) I 0001 0111 I 2.5.5 I I I I I I CIRCUIT GROUP RESET I 0010 1001 I 2.5.6 I I ACKNOWLEDGEMENT (GRA) I I I I I I I I CONNECT (CON) I 0000 0111 I 2.5.7 I I I I I I INITIAL ADDRESS (IAM) I 0000 0001 I 2.5.8 I I I I I I RELEASE (REL) I 0000 1100 I 2.5.9 I I I I I I RELEASE COMPLETE (RLC) I 0001 0000 I 2.5.10 I I I I I I RESET CIRCUIT (RSC) I 0001 0010 I 2.5.11 I I I I I I UNBLOCKING (UBL) I 0001 0100 I 2.5.12 I I I I I I UNBLOCKING I 0001 0110 I 2.5.13 I I ACKNOWLEDGEMENT (UBA) I I I I I I I +---------------------------+-----------+-------------+ 2.5.1 ADDRESS COMPLETE (ACM) Indicates that all the address signals required for routing the call to the called party have been received. direction : backward +-----------------+-----------+------+----------+ I I I I I I parameter I reference I type I length I I I I I (octets) I I I I I I +-----------------+-----------+------+----------+ I I I I I I Message type I 2.5 I F I 1 I I I I I I I Backward call I 2.6.9 I F I 1 I I indicators I I I I I I I I I +-----------------+-----------+------+----------+ 2.5.2 ANSWER (ANM) Indicates that the call has been answered. This message is used to start metering the charge to the calling subscriber. direction : backward +-----------------+-----------+------+----------+ I I I I I I parameter I reference I type I length I I I I I (octets) I I I I I I +-----------------+-----------+------+----------+ I I I I I I Message type I 2.5 I F I 1 I I I I I I +-----------------+-----------+------+----------+ 2.5.3 BLOCKING (BLO) Sent only for maintenance purposes to the node at the other end of a circuit, to cause an engaged condition of that circuit for subsequent calls outgoing from that node. When a circuit is used in the bothway mode of operation a node receiving the blocking message must be capable of accepting incoming calls on the concerned circuit unless it has also sent a blocking message. direction : both +-----------------+-----------+------+----------+ I I I I I I parameter I reference I type I length I I I I I (octets) I I I I I I +-----------------+-----------+------+----------+ I I I I I I Message type I 2.5 I F I 1 I I I I I I +-----------------+-----------+------+----------+ 2.5.4 BLOCKING ACKNOWLEDGEMENT (BLA) Sent in response to a blocking message indicating that the circuit has been blocked. direction : both +-----------------+-----------+------+----------+ I I I I I I parameter I reference I type I length I I I I I (octets) I I I I I I +-----------------+-----------+------+----------+ I I I I I I Message type I 2.5 I F I 1 I I I I I I +-----------------+-----------+------+----------+ 2.5.5 CIRCUIT GROUP RESET (GRS) Sent to release all circuits connected to one NAS when, due to memory mutilation or other causes, it is unknown whether for example, a release or release complete message is appropriate for each of the circuits in the group. If at the receiving end a circuit is remotely blocked, reception of this message should cause that condition to be removed. direction : both +-----------------+-----------+------+----------+ I I I I I I parameter I reference I type I length I I I I I (octets) I I I I I I +-----------------+-----------+------+----------+ I I I I I I Message type I 2.5 I F I 1 I I I I I I +-----------------+-----------+------+----------+ The CIC in the GRS message is not relevant, and will be coded as 0 when sent. 2.5.6 CIRCUIT GROUP RESET ACKNOWLEDGEMENT (GRA) Sent in response to a circuit group reset message and indicating that the requested group of circuits has been reset. direction : both +-----------------+-----------+------+----------+ I I I I I I parameter I reference I type I length I I I I I (octets) I I I I I I +-----------------+-----------+------+----------+ I I I I I I Message type I 2.5 I F I 1 I I I I I I +-----------------+-----------+------+----------+ The CIC in the GRA message is not relevant, and will be coded as 0 when sent. 2.5.7 CONNECT (CON) Indicates that all the address signals required for routing the call to the called party have been received and that the call has been answered. This message is used to start metering the charge to the calling subscriber. direction : backward +-----------------+-----------+------+----------+ I I I I I I parameter I reference I type I length I I I I I (octets) I I I I I I +-----------------+-----------+------+----------+ I I I I I I Message type I 2.5 I F I 1 I I I I I I +-----------------+-----------+------+----------+ 2.5.8 INITIAL ADDRESS (IAM) Initiates seizure of an outgoing circuit and transmits number and other information relating to the routing and handling of a call. direction : forward +-----------------+-----------+------+----------+ I I I I I I parameter I reference I type I length I I I I I (octets) I I I I I I +-----------------+-----------+------+----------+ I I I I I I Message type I 2.5 I F I 1 I I I I I I I Forward call I 2.6.8 I F I 1 I I indicators I I I I I I I I I I Calling party's I 2.6.6 I F I 1 I I category I I I I I I I I I I Transmission I 2.6.10 I F I 1 I I medium I I I I I requirement I I I I I I I I I I Called party I 2.6.4 I V I 2 - 17 I I number I I I I I I I I I I Calling party I 2.6.5 I V I 2 - 10 I I number I I I I I I I I I +-----------------+-----------+------+----------+ 2.5.9 RELEASE (REL) Indicates that the circuit has been released due to the reason (cause) supplied and is ready to be put into the idle state on receipt of the release complete message. direction : both +-----------------+-----------+------+----------+ I I I I I I parameter I reference I type I length I I I I I (octets) I I I I I I +-----------------+-----------+------+----------+ I I I I I I Message type I 2.5 I F I 1 I I I I I I I Cause I 2.6.7 I F I 1 I I indicators I I I I I I I I I +-----------------+-----------+------+----------+ 2.5.10 RELEASE COMPLETE (RLC) Is sent in response to the receipt of a release message, or if appropriate, to a reset circuit message, when the circuit concerned has been brought into the idle condition. direction : both +-----------------+-----------+------+----------+ I I I I I I parameter I reference I type I length I I I I I (octets) I I I I I I +-----------------+-----------+------+----------+ I I I I I I Message type I 2.5 I F I 1 I I I I I I +-----------------+-----------+------+----------+ 2.5.11 RESET CIRCUIT (RSC) Sent to release a circuit when, due to memory mutilation or other causes, it is unknown whether for example, a released or a release complete message is appropriate. If at the receiving end the circuit is blocked, reception of this message should cause that condition to be removed. direction : both +-----------------+-----------+------+----------+ I I I I I I parameter I reference I type I length I I I I I (octets) I I I I I I +-----------------+-----------+------+----------+ I I I I I I Message type I 2.5 I F I 1 I I I I I I +-----------------+-----------+------+----------+ 2.5.12 UNBLOCKING (UBL) Sent to the node at the other end of the circuit to cancel, in that node, the engaged condition of the circuit caused by a previously sent blocking message. direction : both +-----------------+-----------+------+----------+ I I I I I I parameter I reference I type I length I I I I I (octets) I I I I I I +-----------------+-----------+------+----------+ I I I I I I Message type I 2.5 I F I 1 I I I I I I +-----------------+-----------+------+----------+ 2.5.13 UNBLOCKING ACKNOWLEDGEMENT (UBA) Sent in response to an unblocking message indicating that the circuit has been unblocked. direction : both +-----------------+-----------+------+----------+ I I I I I I parameter I reference I type I length I I I I I (octets) I I I I I I +-----------------+-----------+------+----------+ I I I I I I Message type I 2.5 I F I 1 I I I I I I +-----------------+-----------+------+----------+ 2.6 Parameters 2.6.1 FORMAT 2.6.1.1 MANDATORY FIXED PART Those parameters that are mandatory and of fixed length for a particular message type will be contained in the mandatory fixed part. The position, length and order of the parameters is uniquely defined by the message type, thus the names of the parameters and the length indicators are not included in the message. +--------------------------+ I I I MANDATORY PARAMETER A I I I +--------------------------+ . . . ... . . . +--------------------------+ I I I MANDATORY PARAMETER F I I I +--------------------------+ 2.6.1.2 MANDATORY VARIABLE PART Mandatory parameters of variable length will be included in the mandatory variable part. Pointers are used to indicate the beginning of each parameter. Each pointer is encoded as a single octet. The name of each parameter and the order in which the pointers are sent is implicit in the message type. Parameter names are, therefore, not included in the message. The details of how pointers are encoded is found in section 2.6.1.5. The number of parameters, and thus the number of pointers is uniquely defined by the message type. All the pointers are consecutive at the beginning of the mandatory variable part. Each parameter contains the parameter length indicator followed by the contents of the parameters. +--------------------------+ I I I POINTER TO PARAMETER M +--+ I I I +--------------------------+ I . . I . ... . I . . I +--------------------------+ I I I I I POINTER TO PARAMETER P +-----+ I I I I +--------------------------+ I I I I I I I LENGTH OF PARAMETER M I-+ I I I I +--------------------------+ I I I I I PARAMETER M I I I I I +--------------------------+ I . . I . ... . I . . I +--------------------------+ I I I I I LENGTH OF PARAMETER P I----+ I I +--------------------------+ I I I PARAMETER P I I I +--------------------------+ 2.6.1.3 FORMAT OF PARAMETER IN MANDATORY VARIABLE PART +--------------------------+ I I I LENGTH OF PARAMETER M I I I +--------------------------+ I I I PARAMETER M CONTENTS I I I +--------------------------+ 2.6.1.4 CODING OF THE LENGTH INDICATOR The length indicator field is binary coded to indicate the number of octets in the parameter content field. The length indicated does not include the parameter name octet or the length indicator octet. 2.6.1.5 CODING OF THE POINTERS The pointer value (in binary) gives the number of octets between the pointer itself (included) and the first octet (not included) of the parameter associated with that pointer. 2.6.2 PARAMETER NAMES +-----------------------+-----------+-------------+ I I I I I parameter name I code I reference I I I I I +-----------------------+-----------+-------------+ I I I I I CALLED PARTY NUMBER I 0000 0100 I 2.6.4 I I I I I I CALLING PARTY NUMBER I 0000 1010 I 2.6.5 I I I I I I CALLING PARTY'S I 0000 1001 I 2.6.6 I I CATEGORY I I I I I I I I CAUSE INDICATORS I 0001 0010 I 2.6.7 I I I I I I FORWARD CALL I 0000 0111 I 2.6.8 I I INDICATORS I I I I I I I I BACKWARD CALL I 0010 1001 I 2.6.9 I I INDICATORS I I I I I I I I TRANSMISSION MEDIUM I 0000 0010 I 2.6.10 I I REQUIREMENT I I I I I I I +-----------------------+-----------+-------------+ 2.6.3 PARAMETER NAME VS MESSAGE TABLE +-----------------------+-----------+-------------+ I I I I I parameter name I parameter I messages I I I type I I I I I I +-----------------------+-----------+-------------+ I I I I I CALLED PARTY NUMBER I V I IAM I I I I I I CALLING PARTY NUMBER I V I IAM I I I I I I CALLING PARTY'S I F I IAM I I CATEGORY I I I I I I I I CAUSE INDICATORS I F I REL I I I I I I BACKWARD I F I ACM I I CALL INDICATORS I I I I I I I I FORWARD CALL I F I IAM I I INDICATORS I I I I I I I I TRANSMISSION MEDIUM I F I IAM I I REQUIREMENTS I I I I I I I +-----------------------+-----------+-------------+ 2.6.4 CALLED PARTY NUMBER length : 2 - 17 octets 8 7 6 5 4 3 2 1 +----+----------------------------------+ I I IOdd/I Nature of address I IevenI indicator I I I +----+--------------+-------------------+ I I I I 2nd address I 1st address I I signal I signal I I I I +-------------------+-------------------+ I : I I : I I : I +-------------------+-------------------+ I I I I Filler I nth address I I (if necessary) I signal I I I I +-------------------+-------------------+ Odd/Even Indicator 0 Even number of address signals 1 Odd number of address signals Nature of Address Indicator 0 0 0 0 0 0 0 Spare 0 0 0 0 0 0 1 Reserved 0 0 0 0 0 1 0 Reserved 0 0 0 0 0 1 1 National (significant) number 0 0 0 0 1 0 0 International number 0 0 0 0 1 0 1 to 1 1 1 1 1 1 1 Spare Address Signal 0 0 0 0 Digit 0 0 0 0 1 Digit 1 0 0 1 0 Digit 2 0 0 1 1 Digit 3 0 1 0 0 Digit 4 0 1 0 1 Digit 5 0 1 1 0 Digit 6 0 1 1 1 Digit 7 1 0 0 0 Digit 8 1 0 0 1 Digit 9 1 0 1 0 Spare 1 0 1 1 Code 11 1 1 0 0 Code 12 1 1 0 1 Spare 1 1 1 0 Spare 1 1 1 1 Reserved The most significant address signal is sent first. Subsequent address signals are sent in successive 4-bit fields. Filler In the case of odd number of address signals, the filler code 0 0 0 0 is inserted after the last address signal. 2.6.5 CALLING PARTY NUMBER length : 2 - 10 octets 8 7 6 5 4 3 2 1 +----+----------------------------------+ I I I IOdd/I Nature of address I IevenI indicator I I I I +----+--------------+---------+---------+ I I I I I I NI I Reserved IPresent. I Screen- I I I I ind. I ing I I I I I I +----+--------------+---------+---------+ I I I I 2nd address I 1st address I I signal I signal I I I I +-------------------+-------------------+ I : I I : I I : I +-------------------+-------------------+ I I I I Filler I nth address I I (if necessary) I signal I I I I +-------------------+-------------------+ Odd/Even Indicator 0 Even number of address signals 1 Odd number of address signals Nature of Address Indicator 0 0 0 0 0 0 0 Spare 0 0 0 0 0 0 1 Reserved 0 0 0 0 0 1 0 Reserved 0 0 0 0 0 1 1 National (significant) number 0 0 0 0 1 0 0 International number 0 0 0 0 1 0 1 to 1 1 1 1 1 1 1 Spare Screening Indicator 0 0 Not available 0 1 User provided, verified and passed 1 0 Reserved 1 1 Network provided When Sreening Indicator is coded 00 the fields: Nature of Address Indicator, Address Presentation Restricted Indicator and Calling Party Number Incomplete Indicator are not used and coded as 0. Address Presentation Restricted Indicator 0 0 Presentation allowed 0 1 Presentation restricted 1 0 Reserved 1 1 Spare Calling Party Number Incomplete Indicator (NI) 0 Complete 1 Incomplete Address Signal 0 0 0 0 Digit 0 0 0 0 1 Digit 1 0 0 1 0 Digit 2 0 0 1 1 Digit 3 0 1 0 0 Digit 4 0 1 0 1 Digit 5 0 1 1 0 Digit 6 0 1 1 1 Digit 7 1 0 0 0 Digit 8 1 0 0 1 Digit 9 1 0 1 0 Spare 1 0 1 1 Code 11 1 1 0 0 Code 12 1 1 0 1 to 1 1 1 1 Spare The most significant address signal is sent first. Subsequent address signals are sent in successive 4-bit fields. Filler In the case of odd number of address signals, the filler code 0 0 0 0 is inserted after the last address signal. The reserved bits are coded as 0. 2.6.6 CALLING PARTY'S CATEGORY length : 1 octet 8 7 6 5 4 3 2 1 +-----------------------------------------+ I I I CALLING PARTY'S CATEGORY I I I +-----------------------------------------+ Categories 0 0 0 0 0 0 0 0 Reserved to 0 0 0 0 1 0 0 1 Reserved 0 0 0 0 1 0 1 0 Normal subscriber (default) 0 0 0 0 1 0 1 1 Reserved 0 0 0 0 1 1 0 0 Reserved 0 0 0 0 1 1 0 1 Test call 0 0 0 0 1 1 1 0 Reserved to 1 1 1 1 1 1 1 1 Reserved 2.6.7 CAUSE INDICATORS length : 1 octet 8 7 6 5 4 3 2 1 +---+-----------------------------+ I 1 I Cause Value I IextI I +---+-----------------------------+ Cause value Class 0 0 0 and 0 0 1, normal event: 000 0001 (1) Unallocated (unassigned) number 000 0011 (3) No route to destination 000 0100 (4) Send special information tone 001 0000 (16) Normal clearing 001 0001 (17) User busy 001 0010 (18) No user responding 001 0011 (19) No answer from user 001 0101 (21) Call reject 001 0110 (22) Number changed 001 1011 (27) Destination out of order 001 1100 (28) Address incomplete 001 1111 (31) Normal, unspecified Class 0 1 0, resources unavailable: 010 0010 (34) No circuit available 010 0110 (38) Network out of order 010 1001 (41) Temporary failure 010 1010 (42) Switching equipment congestion 010 1100 (44) Requested channel not available 010 1111 (47) Resource unavailable, unspecified Class 0 1 1, service or option not available: 011 1001 (57) Bearer capability not authorized 011 1010 (58) Bearer capability not presently available 011 1111 (63) Service or option not available, unspecified Class 1 0 0, service or option not implemented: 100 0001 (65) Bearer capability not implemented 100 1111 (79) Service or option not implemented, unspecified Class 1 0 1, invalid message (e.g. parameter out of range): 101 1111 (95) Invalid message, unspecified Class 1 1 0, protocol error (e.g. unknown message): 110 0110 (102) Recover on timer expiry 110 1111 (111) Protocol error, unspecified Class 1 1 1, interworking: 111 1111 (127) Interworking, unspecified Extension indicator (ext) 0 Reserved 1 Last octet 2.6.8 FORWARD CALL INDICATORS length : 1 octet 8 7 6 5 4 3 2 1 +---+---+---+---+---+---+---+---+ I I I I I I I I I I H I G I F I E I D I C I B I A I I I I I I I I I I +---+---+---+---+---+---+---+---+ A ISDN access indicator 0 Originating access non-ISDN 1 Originating access ISDN B to H Reserved The reserved bits are coded as 0. 2.6.9 BACKWARD CALL INDICATORS length : 1 octet 8 7 6 5 4 3 2 1 +---+---+---+---+---+---+---+---+ I I I I I I I I I I H I G I F I E I D I C I B I A I I I I I I I I I I +---+---+---+---+---+---+---+---+ A In-band information indicator 0 no-indication 1 in-band information or an appropriate pattern is now available B to H Reserved The reserved bits are coded as 0. 2.6.10 TRANSMISSION MEDIUM REQUIREMENT length : 1 octet 8 7 6 5 4 3 2 1 +---------------------------------+ I I +---------------------------------+ Transmission medium requirement 0000 0000 speech 0000 0001 64 kbit/s restricted 0000 0010 64 kbit/s unrestricted 0000 0011 3.1 khz audio 0000 0100 reserved 0000 0101 reserved 0000 0110 spare 0000 0111 reserved 0000 1000 reserved 0000 1001 reserved 0000 1010 reserved 0000 1011 to 1111 1111 spare 2.7 Message Sequences for Different Traffic Cases 2.7.1 Succsessful Call Set-up and Release 2.7.1.1 Non-auto answer Alerting Indication with Address Complete Indication (A) (B) IAM includes I IAM I all address I --------------------> I signals I I I ACM I Inform A-user I <-------------------- I B user sends ALERT. with ALERT. I I I I I I I I I ANM I The B-user answers, I <-------------------- I ring tone removed. I I ... I I I REL I cause = normal clearing I --------------------> I I RLC I I <-------------------- I Note that NAS will not generate tones. 2.7.1.2 Auto Answer (A) (B) IAM includes I IAM I all address I --------------------> I signals I I I CON I Routing is I <-------------------- I completed, the I I B-user has answered ... I I I REL I cause = normal clearing I --------------------> I I RLC I I <-------------------- I 2.7.2 Signalling in Relation to Blocking 2.7.2.1 Blocking, Single Circuit, Maintenance or Hardware Failure Oriented (A) (B) I I I BLO I I --------------------> I I I I BLA I I <-------------------- I I I 2.7.2.2 Unblocking, Single Circuit, Maintenance or Hardware Failure Oriented (A) (B) I I I UBL I I --------------------> I I I I UBA I I <-------------------- I I I 2.7.3 Interworking Cases 2.7.3.1 ISUP-Etheric, non-auto answer ISUP Etheric (A) ---------------> (B) ---------------> (C) I IAM I I I ------------------> I IAM I I I ------------------> I I I ACM I I ACM I <------------------ I I <------------------ I I I I ANM I I ANM I <------------------ I I <------------------ I I I I I ... I I I I *) REL I I I ------------------> I REL I I RLC I ------------------> I I <------------------ I RLC I I I <------------------ I *) cause = normal clearing 2.7.3.2 ISUP-Etheric, auto answer ISUP Etheric (A) ----------------> (B) ----------------> (C) I IAM I I I ------------------> I IAM I I I ------------------> I I I CON I I ACM I <------------------ I I <------------------ I I I ANM I I I <------------------ I I I I I ... I I I I *) REL I I I ------------------> I REL I I RLC I ------------------> I I <------------------ I RLC I I I <------------------ I *) cause = normal clearing 2.7.3.3 DSS1-Etheric DSS1 Etheric (A) ----------------> (B) ----------------> (C) I SETUP I I I ------------------> I I I CALL PROC I I I <------------------ I IAM I I I ------------------> I I I ACM I I ALERTING I <------------------ I I <------------------ I I I I I I I ANM I I CONNECT I <------------------ I I <------------------ I I I I I I CONN ACK I I I ------------------> I I ... I I I I *) DISCONNECT I I I ------------------> I REL I I RELEASE I ------------------> I I <------------------ I RLC I I REL COM I <------------------ I I ------------------> I I *) cause = normal clearing 2.8 Basic Call Control and Signalling Procedures 2.8.1 Basic Procedures The basic call control procedure is divided into three phases; call set-up, the data/conversation phase and call clear-down. Messages are used to establish and terminate the different phases of a call. Standard inband supervisory tones are returned to the caller to provide information on call progress. 2.8.2 Successful Call Set-up from PSTN-GW to NAS 2.8.2.1 Forward address signalling a) Circuit selection When the originating exchange has received the complete selection information from the calling party (or an intermediate exchange has received the information via ISUP or other inter-exchange signalling), and has determined that the call is to be routed to target organisation, selection of a suitable, free circuit takes place and an Initial Address Message is sent to NAS. The selection of the route will depend on the called party number and connection type required. In addition, in the case of a subscriber with digital access, the set-up message contains bearer capability information which is analyzed by the originating exchange to determine the correct connection type. The information received from the access interface is used to set the value of the Transmission Medium Requirement parameter. At an intermediate exchange the connection type is set according to the signalling information received via inter-exchange signalling. The connection types allowed are: - speech. - 64 kbit/s restricted. - 64 kbit/s unrestricted. - 3.1 kHz audio. The connection type will be included in the Initial Address Message, (as Transmission Medium Requirement). The Initial Address Message conveys implicitly the meaning that the indicated circuit has been seized. b) Initial Address Message The Initial Address Message contains all the information that is required to route the call to the correct target organisation. All Initial Address Messages will include a Calling Party Category Parameter, a Called Party Number Parameter (minimum of 1 address signal), a Calling Party Number Parameter (can have an indicator that calling party number is not included) and a Transmission Medium Requirement Parameter. The Transmission Medium Requirement Parameter contains the connection type e.g. 64 kbit/s unrestricted. c) Completion of transmission path Through connection of the transmission path will be completed in the backward direction immediately after the reception of the Address Complete Message (the transmission path is completed in the forward direction on receipt of a Connect or Answer Message). d) Await address complete When the PSTN-GW has sent the Initial Address Message the awaiting address complete timer T7 is started. If timer T7 expires the connection is released and an indication is returned to the calling subscriber. 2.8.2.2 Address Complete Message and Connect Message Return of Address Complete Message from NAS An Address Complete Message will be sent from the NAS as soon as it has reserved all necessary resources to handle the incoming call (connected the modem etc.). Return of Connect Message from NAS The Connect Message signifies both address complete and answer conditions. Receipt of Address Complete/Connect Message at PSTN-GW Intermediate exchange Upon receipt of an Address Complete Message an intermediate exchange will send the corresponding Address Complete Message to the preceding exchange. If this is the controlling exchange the awaiting answer timer(T9) is started. If timer(T9) expires the connection is released and an indication is sent to the calling subscriber. If a Connect Message is received at an intermediate exchange instead of an Address Complete Message, a Connect Message will be sent to the preceding exchange. Originating exchange a) On receipt of an Address Complete Message an alerting indication is passed to the calling party if possible. b) On receipt of the Address Complete Message the awaiting address complete timer (T7) is stopped and the awaiting answer timer (T9) is started if this is the controlling exchange. If timer (T9) expires the connection is released and an indication is sent to the calling subscriber. c) If the Connect Message is received then, the awaiting address complete timer(T7) is stopped. 2.8.2.3 Answer Message On detection of answer the controlling exchange will stop timer (T9). Return of Answer Message from NAS When the call is connected to the target organisation the NAS terminates the transmission path and the ringing tone is removed if applicable. An Answer Message to the PSTN-GW is sent. Receipt of Answer Message at PSTN-GW When the PSTN-GW receives an Answer Message indicating the required connection has been completed, the transmission path is connected through in the forward direction, if not already connected. The calling party is informed (originating exchange) or a corresponding Answer Message is sent to the preceding exchange (intermediate exchange). Return of answer from automatic terminals When connections are set-up to terminals having an automatic answer feature, the alerting indication may not be received. When the connection from NAS to target organisation is set up an Answer Message is sent provided that an Address Complete Message has been sent, otherwise the Connect Message is sent. 2.8.3 Successful Call Set-up from NAS to PSTN-GW 2.8.3.1 Forward address signalling a) Selection of called party Upon receipt of an Initial Address Message the destination exchange will analyze the called party number to determine to which party the call should be connected. It will also check the called party's line condition. If the connection is allowed the destination exchange will setup a connection to the called party. An intermediate exchange, on receipt of an Initial Address Message, will analyze the called party number and the other routing information (TMR) to determine the routing of the call. If the intermediate exchange can route the call using the connection type specified in the Transmission Medium Requirement Parameter, a free inter-exchange circuit is seized and an Initial Address Message (or corresponding signalling information in other signalling systems) is sent to the succeeding exchange. 2.8.3.2 Address Complete Message and Connect Message Return of Address Complete Message from destination exchange An Address Complete Message will be sent from the destination exchange as soon as it has been determined that the complete called party number has been received, or an alerting indication is received from the called party. However there is no direct mapping from alerting, received from the access signalling system, to address complete. Return of Connect Message from the destination exchange If a connect indication is received from the ISDN access under the following conditions, - no alerting indication received from the ISDN access, and - an Address Complete Message has not yet been sent by the destination exchange, a Connect Message is sent by the destination exchange. This Connect Message signifies both address complete and answer conditions. The destination exchange will through connect before the Connect Message is sent. Receipt of Address Complete/Connect Message at an intermediate exchange Upon receipt of an Address Complete/Connect Message an intermediate exchange will send an Address Complete/Connect Message to NAS. 2.8.3.3 Answer Message Return of Answer Message When the called party answers (destination exchange), or if Answer Message (or corresponding signalling information) is received (intermediate exchange), PSTN-GW connects through the transmission path and the ringing tone is removed if applicable. An Answer Message to NAS is sent. 2.8.4 Unsuccessful Call Set-up If at any time in the call set-up the connection cannot be completed a Release Message is returned. This message contains the reason (cause code). 2.8.4.1 Actions at the node initiating a Release Message The initiating node (PSTN-GW or NAS) immediately starts the release of the switched path (if established). The node sends a Release Message to the other node and timers T1 and T5 are started to ensure that a Release Complete Message is received. (Expiration of timers T1 and T5 are covered in section 2.8). 2.8.4.2 Actions at the node receiving a Release Message On receipt of a Release Message, the release of the switched path is started. In addition, the receiving node will (if applicable) attempt to re-route the call. When the switched path is released, a Release Complete Message is sent. 2.8.5 Normal Call Release The release procedures are based on a two message (Release, Release Complete) approach whereby the Release Message initiates release of the circuit switched connection. The same procedures are used irrespective of whether the release is initiated from PSTN-GW or NAS. Actions at the release initiating node On receipt of a request to release the call, the node immediately starts the release of the switched path. A Release Message is sent to the other node and timers T1 and T5 are started to ensure that a Release Complete Message is received. Actions at the release receiving node On receipt of a Release Message, the node will start the release of the switched path. When the switched path is released a Release Complete Message is returned to the other node. 2.8.5.1 Collision of Release Messages In the case when two points in the connection both initiate the release of a call, a Release Message may be received after the release of the switched path is initiated. In this case, a Release Complete Message is returned to the node from which the concerned Release Message was received. The Release Complete Message will be sent when the switched path is released. 2.8.6 Network Features 2.8.6.1 Automatic repeat attempt Automatic repeat attempt, as defined in Recommendation Q.12 is provided: i) on detection of dual seizure (at the non-control node); ii) on receipt of a Blocking Message after sending an Initial Address Message and before any backward message has been received; iii) on receipt of a Reset Circuit Message after sending an Initial Address Message and before a backward message has been received; iv) on receipt of an unreasonable message during call set up. 2.8.6.2 Blocking and unblocking of circuits The Blocking and Unblocking Messages are provided to permit the switching equipment or maintenance system to remove from (and return to) traffic, circuits because of a fault or to permit testing. Since the circuits have bothway capability, the Blocking Message can be originated by either node. The receipt of a Blocking Message, will have the effect of, prohibiting non test calls on the relevant circuit outgoing from the PSTN-GW and all calls from NAS (Test calls are only initiated from PSTN-GW to NAS). This condition will remain until an Unblocking Message is received, but will not prohibit test calls incoming to the NAS. Test calls generated in the outgoing direction from the PSTN-GW that sent the Blocking Message will also be processed. Non-test Initial Address Messages will result in an abnormal case. An acknowledgement sequence is always required for the Blocking and Unblocking Message. This is performed using the Blocking Acknowledgement Message or the Unblocking Acknowledgement Message. The acknowledgement is not sent until the appropriate action, either blocking or unblocking has been taken. The Release Message should not override a blocking message and return circuits to service which might be faulty. The blocked circuit will be returned to service: - on transmission of the Unblocking Acknowledgement Message at one end, - on reception of the Unblocking Acknowledgement Message at the other end. Other actions on receipt of a Blocking Message In the event of a Blocking Message being received, after an Initial Address Message has been sent in the opposite direction on that circuit, and before a backward message relating to that call has been received, an automatic repeat attempt will be made on another circuit. The node receiving the Blocking Message releases the original call attempt in the normal manner after sending the Blocking Acknowledgement Message and will not seize that circuit for subsequent calls. If the Blocking Message is received - after an Initial Address Message has been sent for that circuit in the opposite direction and after at least one backward message relating to that call has been received, or - after an Initial Address Message has been received for that circuit beforehand, the node will not seize that circuit for subsequent calls. The fact that the circuit is engaged on a call will not delay transmission of the Blocking (Unblocking) Acknowledgement Message. If a Blocking Message is sent and subsequently an Initial Address Message is received in the opposite direction, the following action is taken; - for test calls, the call should be accepted in NAS, if possible. In the case where the test call cannot be accepted, the Blocking Message must be repeated; - for calls other than test calls, the Blocking Message must be repeated and the Initial Address Message discarded. When a circuit is blocked by use of the Blocking Message the maintenance system should be informed at both ends of the circuit. Abnormal blocking procedures The following procedures are designed to cover abnormal cases which may occur in the blocking/unblocking procedures. i) if a Blocking Message is received for a blocked circuit, a Blocking Acknowledgement Message will be sent; ii) if an Unblocking Message is received for an unblocked circuit, an Unblocking Acknowledgement Message will be sent. iii) if a Blocking Acknowledgement Message, which is not expected as an acknowledgement for a Blocking Message, is received; - relating to a circuit which is locally blocked, the Blocking Acknowledgement Message is discarded; - relating to a circuit which is not locally blocked, then the maintenance system is notified. iv) if an Unblocking Acknowledgement Message, which is not an expected response to an Unblocking Message, is received; - relating to a circuit which is not locally blocked, the received Unblocking Acknowledgement Message is discarded; - relating to a circuit which is locally blocked then the maintenance system is notified. v) If a non test Initial Address Message is received on a remotely blocked circuit, the remotely blocked state of the circuit is removed and the Initial Address Message is processed normally unless the circuit is also locally blocked in which case the Initial Address Message is discarded. However it should not be the preferred method of unblocking a circuit. 2.8.7 Abnormal Conditions 2.8.7.1 Dual seizure Because circuits have the capability of bothway operation, it is possible that the two nodes will attempt to seize the same circuit at approximately the same time. Detection of dual seizure A dual seizure is detected by a node from the fact that it receives an Initial Address Message for a circuit for which it has sent an Initial Address Message, but before it receives a valid backwards message. Preventive Action An opposite order of selection is used at each node of a bothway circuit group. PSTN-GW will always select circuits from the lowest device (CIC) number end and NAS from the highest device number of a circuit group. Actions to Be Taken on Detection of Dual Seizure The PSTN-GW will control all circuits. On detection of a dual seizure, the call being processed by the controlling node (PSTN-GW) for that circuit will be completed and the received Initial Address Message will be disregarded. Under these conditions, the call being processed by the controlling node will be allowed to continue. The call being processed by the non-controlling node will be dropped and the switch-path released. A Release Message will not be sent. The non-controlling node will make an automatic repeat attempt on the same or on an alternative route. 2.8.7.2 Reset of circuits In systems which maintain circuit status in memory there may be occasions when the memory becomes mutilated. In such a case the circuits must be reset to the idle condition at both nodes to make them available for new traffic. Since the system with the mutilated memory does not know whether the circuits are idle, busy outgoing, busy incoming, blocked, etc., Reset Circuit Messages or a Circuit Group Reset Message should be sent as appropriate for the affected circuits. Reset Circuit Message On receipt of a Reset Circuit Message the receiving (unaffected) node will; a) if it is the incoming or outgoing node on a connection in any state of call set-up or during a call, accept the message as a Release Message and respond by sending a Release Complete Message, after the circuit has been made idle; b) if the circuit is in the idle condition, accept the message as a Release Message and respond by sending a Release Complete Message; c) if it has previously sent a Blocking Message, or if it is unable to release the circuit as described above, respond with a Blocking Message. If an incoming or outgoing call is in progress, this call should be released and the circuit returned to the blocked condition. A Release Complete Message is sent following the Blocking Message. The Blocking Message should be acknowledged by the affected exchange. If the acknowledgement is not received, the repetition procedure should be followed; d) if it has previously received a Blocking Message, respond by releasing a possible outgoing call or call attempt on the circuit, remove the blocked condition, restore the circuit to the idle state, and respond with a Release Complete Message; e) if the message is received after the sending of an Initial Address Message but before receipt of a backward message relating to that call, clear the circuit and make an automatic repeat attempt on another circuit if appropriate; f) if the message is received after having sent a Reset Circuit Message, respond by a Release Complete Message. After receipt of the appropriate acknowledgement message, the circuit should be made available for service. g) clear any interconnected circuits by the appropriate method (e.g. release). The affected node will then reconstruct its memory according to the received response(s) to the Reset Circuit Message, and respond to the message(s) in the normal way i.e. send Blocking Acknowledgement Message in response to a Blocking Message. If the circuit is in a blocked condition, blocking procedures should be re-initiated. If no Release Complete Message is received in acknowledgement to the Reset Circuit Message within time T16, the Reset Circuit Message should be repeated. If an acknowledgement for the message is not received within time T17 after the initial Reset Circuit Message, the maintenance system should be notified. However, the sending of the Reset Circuit Message should continue at time T17 intervals until maintenance intervention occurs. Circuit Group Reset Message If all circuits at either node are affected by a memory mutilation, Circuit Group Reset Message should be used to make them available for new traffic. On receipt of a Circuit Group Reset Message the receiving (unaffected) node will; a) restore the circuits to the idle state; b) send the appropriate Blocking Message(s) if it had previously sent Blocking Message(s); c) respond by a Circuit Group Reset Acknowledgement Message; d) if it had previously received (a) Blocking Message(s) for one or more of the circuit(s) involved, the blocked condition will be removed and the circuits will be made available for service; e) if a Circuit Group Reset Message is received after having sent a Circuit Group Reset Message or a Reset Circuit Message the concerned circuits, are made available for service after receipt of the appropriate acknowledgement message; f) appropriate messages should be sent on interconnected circuits to release them. The affected node will then reconstruct its memory according to the possibly received Blocking Messages and the received Circuit Group Reset Acknowledgement Message. It will respond to the possibly received Blocking Messages in the normal way. If the circuit is in a blocked condition, blocking procedures should be re-initiated. If no acknowledgement to a Circuit Group Reset Message is received within time T22, the Circuit Group Reset Message should be repeated. If an acknowledgement for the Circuit Group Reset Message is not received within time T23 after sending the initial Circuit Group Reset Message the maintenance system should be notified. However, the sending of the Circuit Group Reset Message should continue at time T23 intervals until maintenance intervention occurs. Abnormal circuit group reset message procedures i) if a Circuit Group Reset Acknowledgement Message is received which is not a correct response to a sent Circuit Group Reset Message, it is discarded. 2.8.7.3 Failure in the blocking/unblocking sequence A node will repeat the Blocking (Unblocking) Message on failure to receive the appropriate acknowledgement in response to one of these messages before the respective timer T12 (T14) expires. If the appropriate acknowledgement is not received within time T13 (T15) after sending the initial Blocking (Unblocking) Message, the maintenance system should be alerted, the repetition of the Blocking (Unblocking) Message should be continued at time T13 (T15) intervals until maintenance intervention occurs and the circuit is taken out of (returned to) service as appropriate. 2.8.7.4 Receipt of unreasonable/unrecognized signalling information Messages Undetected errors at the TCP/IP level and exchange malfunctions may produce signalling information Messages that are either ambiguous or inappropriate. The following are considered message format errors: a) The message length is less than the number of octets required for the fixed mandatory part and the mandatory variable pointers. b) A mandatory variable pointer points beyond the message length. c) A mandatory variable causes the overall message length to be exceeded. When a message format error is detected the message shall be discarded. Note : A format error can only be detected when the message is recognized. For the purposes of format error detection, the message length is interpreted as the received message length. Message format error checks are performed on all messages. The procedures listed below do not include the procedures for blocking, unblocking and reset, these are covered in separate sections. Handling of unrecognized information Unrecognized messages and parameters should be discarded without disrupting normal call handling. Unrecognized parameter values should be handled according to the Table 1. The following actions are defined Default : Handle as if default value was received Discard Parameter : Entire parameter is discarded Release : Call is released with appropriate cause value Table 1 Required Actions for Unrecognised Parameter Values +----------------------------------+--------------------------------+ I I I I Parameter Field Name I Required Action I I I I +----------------------------------+--------------------------------+ I I I I Called Party Number I I I . Nature of address indicator I Send release with cause 28 I I . Address signals I Send release with cause 28 I I . Filler I Default: 0000 I I I I +----------------------------------+--------------------------------+ I I I I Calling Party Number I I I . Nature of address indicator I Discard parameter I I . Address presentation I Default: 01 'presentation I I restricted indicator I restricted' I I . Screening indicator I Discard parameter I I . Address signals I Discard parameter I I . Filler I Default: 0000 I I I I +----------------------------------+--------------------------------+ I I I I Calling Party's Category I I I . Categories I Default: 0000 1010 'ordinary I I I subscriber'I I I I +----------------------------------+--------------------------------+ I I I I Cause Indicators I I I . Cause value I Default: 'Unspecified within I I I class xxx' I I I I +----------------------------------+--------------------------------+ I I I I Transmission Medium Requirement I I I . Transmission medium requirementI Send release with cause 65 I I I I +----------------------------------+--------------------------------+ 2.8.7.5 Handling of Unexpected Messages An unexpected message is one which contains a valid message type code but has been received in the wrong phase of the call. In order to resolve possible ambiguities in the state of a circuit when unexpected messages are received the following will apply; a) if a Release Message is received relating to an idle circuit it will be acknowledged with a Release Complete Message; b) if a Release Complete Message is received relating to an idle circuit it will be discarded; c) if a Release Complete Message is received relating to a busy circuit for which a Release Message has not been sent, the circuit will be released and a Release Message will be sent. d) if other unexpected messages are received, the following actions will be undertaken; - if the circuit is idle, the Reset Circuit Message is sent; - if the circuit has been seized by a call, after receipt of a backward message required for the call set-up, the unreasonable signalling information is discarded; - if the circuit has been seized by a call, before receipt of a backward message required for the call set-up, the Reset Circuit Message is sent. If the circuit is seized by an incoming call, the call will be released. If the circuit is seized by an outgoing call, an automatic repeat attempt is provided on another circuit. 2.8.7.6 Failure to receive a "Release Complete" Message - Time T1 and T5 If a Release Complete Message is not received in response to a Release Message before time T1, the Release Message is retransmitted. If no Release Complete Message is received on the expiry of timer T5, the node shall; i) send a Reset Circuit Message; ii) alert the maintenance system; iii) remove the circuit from traffic; iv) continue the sending of the Reset Circuit Message at time T17 intervals until maintenance action occurs. 2.8.7.7 Other Failure Conditions Call-failure The call-failure indication (cause #31) is sent in a Release Message whenever a call attempt fails and other specific signals do not apply. Reception of the Release Message at intermediate exchange will cause the Release Message to be sent to preceding exchanges. If the signalling does not permit theRelease Message to be sent, the appropriate signal, tone or announcement is sent to the preceding exchange. 2.8.8 Start-up Procedures The start-up procedure between PSTN-GW and NAS is a manually controlled procedure. It is initiated by PSTN-GW for each circuit. After the start-up procedure the circuits are in manually blocked condition. During the process of placing circuits into service, unacknowledged circuit supervision messages will most likely be reported to maintenance system. In order to minimize this impact, it is recommended that coordination takes place between PSTN-GW and NAS and established procedures for placing circuits into service be followed (Circuits are first taken into service in NAS and then in PSTN-GW). Lack of coordination may result in inefficient use of exchange and maintenance resources. 2.8.8.1 Initial procedure for putting circuits into service PSTN-GW ----> NAS -----RSC----> <----RLC----- * <----BLO----- -----BLA----> -----BLO----> ** <----BLA----- *) PSTN-GW updates the remote blocking condition (Circuit blocked in NAS) **) NAS updates the remote blocking condition (Circuit blocked in PSTN-GW) Circuits are deblocked PSTN-GW ----> NAS -----UBL----> (1) <----UBA----- <----UBL----- (2) -----UBA----> (1) Circuit is deblocked in PSTN-GW. (2) Circuit is deblcoked in NAS. (The circuits can be deblocked first either in NAS or PSTN-GW.) The Circuits are now ready for traffic. 2.8.9 Loadsharing The signalling is loadshared between the two TCP connections. The messages with even CIC use one TCP connection, and the messages with odd CIC the other connection. Following conditions are exceptions to that principle: All messages are then sent on the working TCP connection, if the other connection is not working. Group Reset Message is always acknowledged using the same TCP connection upon which it was received. Blocking messages are always acknowledged using the same TCP connection upon which it was received. The reason for this is the exchange of blocking messages after restart situations when one TCP connection may not be started yet. 2.8.10 TCP/IP Connection Break If the TCP/IP connection (or both connections in case of duplicated Ethernet) between PSTN-GW and NAS goes down, the following actions take place: - All circuits are blocked for new calls. - Calls in set-up phase are released without exchanging release messages. - Calls in Active state are kept. PSTN-GW tries to open the TCP/IP connection after a supervised time. If the opening does not succeed, PSTN-GW retries to open the connection until it succeeds. The time, after which PSTN-GW tries to open the connection, is 2 - 3 seconds at the first try. After that the supervision time is increased at each try, until the maximum time limit is reached. After that the a new try is done with an interval of the maximum time. The timeout values are: - Increase step 1 - 120 seconds, default value 15 seconds - Maximum interval 4 - 300 seconds, default value 120 seconds When the TCP/IP connection (at least one connection in case of duplicated Ethernet) comes up, the following actions take place: - All circuits are deblocked. - A Reset Circuit Message is sent for the calls that were released during the time the TCP/IP connections were down. 2.9 Timers +--------+--------------+----------------------------+ I I I I I SYMBOL I TIME-OUT I CAUSE FOR INITIATION I I I VALUE I I I I I I +--------+--------------+----------------------------+ I I I I I T 1 I4-60 IWhen Release Message is I I ISeconds Isent I I I I I +--------+--------------+----------------------------+ I I I I I T 5 I1-15 IWhen initial Release I I IMinutes IMessage is sent I I I I I +--------+--------------+----------------------------+ I I I I I T 7 I20-30 IWhen Initial Address I I ISeconds IMessage is sent I I I I I +--------+--------------+----------------------------+ I I I I I T 9 I1-4 IWhen Address Complete I I IMinutes IMessage is received I I I I I +--------+--------------+----------------------------+ I I I I I T 12 I4-60 IWhen Blocking Message is I I ISeconds Isent I I I I I +--------+--------------+----------------------------+ I I I I I T 13 I1-15 IWhen initial Blocking I I IMinutes IMessage is sent I I I I I +--------+--------------+----------------------------+ I I I I I T 14 I4-60 IWhen Unblocking Message is I I ISeconds Isent I I I I I +--------+--------------+----------------------------+ I I I I I T 15 I1-15 IWhen initial Unblocking I I IMinutes IMessage is sent I I I I I +--------+--------------+----------------------------+ I I I I I T 16 I4-60 IWhen Reset Circuit Message I I ISeconds Iis sent not due to expiry I I I Iof T5 I I I I I +--------+--------------+----------------------------+ I I I I I T 17 I1-15 IWhen initial Reset Circuit I I IMinutes IMessage is sent I I I I I +--------+--------------+----------------------------+ I I I I I T 22 I4-60 IWhen Circuit Group Reset I I ISeconds IMessage is sent I I I I I +--------+--------------+----------------------------+ I I I I I T 23 I1-15 IWhen initial Circuit Group I I IMinutes IReset Message is sent I I I I I +--------+--------------+----------------------------+ +--------+--------------------------+---------------------------------+ I I I I I SYMBOL I NORMAL TERMINATION I AT EXPIRY I I I I I +--------+--------------------------+---------------------------------+ I I I I I T 1 I At receipt of the I Retransmit Release Message and I I I Release Complete message I start timer T1 I I I I I +--------+--------------------------+---------------------------------+ I I I I I T 5 I At receipt of the I Send Reset Circuit Message, I I I Release Complete message I alert maintenance personnel and I I I I remove the circuit from I I I I service, stop T1, start T17. I I I I Procedure continues until I I I I maintenance intervention I I I I occurs. I I I I I +--------+--------------------------+---------------------------------+ I I I I I T 7 I When the condition for I Release all equipment and I I I normal release of I connection I I I address and routing I (Send Release Message) I I I information is met ( I I I I receipt of ACM, CON, I I I I messages) I I I I I I +--------+--------------------------+---------------------------------+ I I I I I T 9 I At the receipt of Answer I Release connection I I I Message I send back Release Message I I I I I +--------+--------------------------+---------------------------------+ +--------+--------------------------+---------------------------------+ I I I I I SYMBOL I NORMAL TERMINATION I AT EXPIRY I I I I I +--------+--------------------------+---------------------------------+ I T 12 I At receipt of Blocking I Retransmit Blocking Message I I I Acknowledgement Message I and restart T12 I +--------+--------------------------+---------------------------------+ I T 13 I At receipt of Blocking I Retransmit Blocking Message, I I I Acknowledgement Message I alert maintenance personnel, I I I I restart T13 and stop T12. I I I I Procedure continues until I I I I maintenance intervention I I I I occurs. I +--------+--------------------------+---------------------------------+ I T 14 I At receipt of Unblocking I Retransmit Unblocking Message I I I Acknowledgement Message I and restart T14 I +--------+--------------------------+---------------------------------+ I T 15 I At receipt of Unblocking I Retransmit Unblocking Message I I I Acknowledgement Message I alert maintenance personnel, I I I I restart T15 and stop T14. I I I I Procedure continues until I I I I maintenance intervention I I I I occurs. I +--------+--------------------------+---------------------------------+ I T 16 I At the receipt of the I Retransmit Reset Circuit I I I Release Complete Message I Message and restart T16 I I I (acknowledgement) I I +--------+--------------------------+---------------------------------+ I T 17 I At the receipt of the I Alert maintenance personnel, I I I Release Complete Message I retransmit Reset Circuit I I I (acknowledgement) I Message, restart T17, stop T16. I I I I Procedure continues until I I I I maintenance intervention I I I I occurs. I +--------+--------------------------+---------------------------------+ I T 22 I At the receipt of the I Retransmit Circuit Group Reset I I I Circuit Group Reset I Message and restart T22 I I I Acknowledgement Message I I +--------+--------------------------+---------------------------------+ I T 23 I At the receipt of the I Alert maintenance personnel, I I I Circuit Group Reset I retransmit Circuit Group Reset I I I Acknowledgement Message I Message, restart T23, stop T22. I I I I Procedure continues until I I I I maintenance intervention I I I I occurs. I +--------+--------------------------+---------------------------------+ 3. References [1] ITU-T Recomendation Q.767. Specifications of Signalling system No. 7. Applications of the ISDN User Part of CCITT Signalling System No. 7 for international ISDN connections. 4. Intellectual property rights Authors are not aware of any IPR issues covering this draft. However, we have not done a proper screening on this and it may be that there are some patents, even inside Ericsson, covering all or part of this internet draft. 5. Authors Harri Toivanen Oy LM Ericsson Ab 02420 JORVAS Finland Phone: +358-9-299 2247 Email: Harri.Toivanen@ericsson.com Petteri Laamo Oy LM Ericsson Ab 02420 JORVAS Finland Phone: +358-9-299 2747 Email: Petteri.Laamo@lmf.ericsson.se George Wayne Advanced Computer Communications 340 Storke Road Santa Barbara, CA 93117 U.S.A. Email: gwayne@acc.com Paul Harding-Jones Advanced Computer Communications 340 Storke Road Santa Barbara, CA 93117 U.S.A. Email: phj@acc.com