2.9.3	Circuit group query
2.9.3.1	General
	The circuit group query test allows an exchange to audit the state of a circuit on a demand or routine basis.
	The value N of the range field of the circuit group query message, including N=0 for a single circuit, indicates the range to be tested. The maximum value of N is 31. If that value is exceeded the circuit group query message is discarded.
2.9.3.2	Interpretation of circuit states
	For the purposes of circuit query procedures, there are states which are classified into four major categories, as follows:
1)	unequipped and transient conditions,
2)	call processing states,
3)	maintenance blocking states,
4)	hardware blocking states.
	The two states “unequipped” and “transient” do not overlap with other states.
	Call processing states include:
1)	idle,
2)	circuit incoming busy,
3)	circuit outgoing busy.
	Maintenance blocking states include:
1)	unblocked,
2)	remotely blocked,
3)	locally blocked,
4)	locally and remotely blocked.
	Hardware blocking states include:
1)	unblocked,
2)	remotely blocked,
3)	locally blocked,
4)	locally and remotely blocked.
	A circuit is “unequipped” if the circuit is not available for ISDN user part. Call processing or maintenance action cannot be performed on it. This is a unique state and will not overlap with any other state.
	The “transient” state refers to any transient call processing or maintenance states.
	Call processing is in a transient state
a)	after having sent an initial address message and waiting for the first backward message (whether a suspended call is in a transient state in the context of circuit group query is for further consideration), or
b)	after having sent a release message and waiting for the release complete message.
	Transient maintenance states are those, where the exchange after having sent a (group) (un)blocking message is awaiting the proper (group) (un)blocking acknowledgement message from the remote exchange.

	The circuit state is also considered transient as long as a circuit (group) reset message has not been acknowledged.
	The “idle” state is a call–processing state of an equipped, non–busy circuit. The “circuit incoming busy” or “circuit outgoing busy” refers to a stable call processing state.
	The hardware or maintenance “remotely blocked” state refers to the state marked by the exchange when the far–end exchange initiates blocking. The maintenance blocking state can co–exist with “idle”, “circuit incoming busy”, or “circuit outgoing busy” state. The hardware blocking state can only co–exist with the “idle” call processing state, as calls are immediately released when hardware blocking is invoked.
	The hardware or maintenance “locally blocked” state refers to the state marked by the exchange when it initiated blocking to the far–end exchange and the proper acknowledgement was received. The maintenance blocking state can co–exist with “idle”, “circuit incoming busy”, or “circuit outgoing busy” state. The hardware blocking state can only co–exist with the “idle” call processing state, as calls are immediately released when hardware blocking is invoked.
	To initiate the circuit group query procedure, the sending exchange sends a circuit group query message indicating in the routing label and range field those circuits to be audited. If no response to the circuit group query message is received before timer (T34 12–15 seconds) expires, maintenance systems should be informed.
	The receiving exchange will process the circuit group query message, and return a circuit group query response message setting the circuit state indicators to the state of the circuits being audited.
	If this circuit group procedure uncovers discrepancies in the state of a circuit as perceived at the two ends. The action to be taken in order to align the two views are for further study.
2.10	Abnormal conditions
2.10.1	Dual seizure
	Because Signalling System No. 7 circuits have the capability of bothway operation, it is possible that the two exchanges will attempt to seize the same circuit at approximately the same time.
2.10.1.1	Unguarded interval
	The exchange must detect dual seizure and take action as defined in § 2.10.1.4.
2.10.1.2	Detection of dual seizure
	A dual seizure is detected by an exchange 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.
2.10.1.3	Preventive action
	Different methods for circuit selection can be envisaged to minimise the occurrence of dual seizure. In the following, two methods are described. Further study is required to determine the field of application of each method and to ensure that the two methods do inter–work satisfactorily.
	Other methods for circuit selection may also be used provided that they give the same degree of protection against dual seizure also when one of the methods specified is used at the other end.
	Method 1
	An opposite order of selection is used at each exchange of a bothway circuit group.
	Method 2
	Each exchange of a bothway circuit group has priority access to the group of circuits which it is controlling (see § 2.10.1.4). Of this group the circuit which has been released the longest is selected (first–in, first–out). In addition each exchange of a bothway circuit group has non–priority access to the group of circuits which it is non–controlling. Of this group the latest released circuit is selected (last–in, first–out) if all circuits in the group are busy.

	For call control purposes a bothway circuit group can be subdivided into subgroups in an exchange.
	It is necessary to take preventive action in cases where Signalling System No. 7 uses a signalling data link with long propagation time.
2.10.1.4	Action to be taken on detection of dual seizures
	Each exchange will control one half of the circuits in a bothway circuit group. On detection of a dual seizure, the call being processed by the control exchange for that circuit will be completed and the received initial address message will be disregarded.
	Under these conditions, the call being processed by the control exchange will be allowed to mature. The call being processed by the non–control exchange will be backed off and the switch–path released. A release message will not be sent. The non–control exchange will make an automatic repeat attempt on the same or on an alternative route.
	For the purpose of resolution of dual seizure on bothway circuits, the exchange with the higher signalling point code will control all even–numbered circuits (circuit identification code) and the other exchange the odd–numbered circuits. The designation of control may also be used for maintenance system purposes.
2.10.2	Transmission alarm handling for digital inter–exchange circuits
	When fully digital circuits are provided between two exchanges, which have some inherent fault indication feature giving an indication to the switching system when faults on tansmission systems are detected, the switching system should inhibit selection of the circuits concerned for the period the fault conditions persist.
2.10.3	Reset of circuits and circuit groups
	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 exchanges to make them available for new traffic. Since the exchange 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.
2.10.3.1	Reset circuit message
	If only a few circuits are concerned a reset circuit message should be sent for each affected circuit.
	On receipt of a reset circuit message the receiving (unaffected) exchange will:
a)	if it is the incoming or outgoing exchange 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 by the blocking message. If an incoming or outgoing call is in progress, this call should be released and the circuit returned to the “idle, blocked” state. 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 specified in § 2.10.4 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. The circuit should be restored to the idle state;
g)	clear any interconnected circuits by the appropriate method (e.g. release).

	The affected exchange will then reconstruct its memory according to the received response(s) to the reset circuit and respond to the message(s) in the normal way, i.e. blocking acknowledgement message in response to a blocking message.
	If no release complete message is received in acknowledgement to the reset circuit message before 4–15 seconds, the reset circuit message should be repeated. If an acknowledgement for the message is not received within 1 minute after the initial reset circuit message, the maintenance system should be notified. However, the sending of the reset circuit message should continue at 1 minute intervals until maintenance intervention occurs.
2.10.3.2	Circuit group reset message
	If a considerable number of circuits or all circuits are affected by a memory mutilation, (a) circuit group reset message(s) should be used to make them available for new traffic.
	The maximum number of circuits to be reset with a circuit group reset message is limited to 32.
	On receipt of a circuit group reset message the receiving (unaffected) exchange will:
a)	restore the circuits to the idle state;
b)	send the appropriate circuit group blocking message(s) if it had previously sent a hardware failure oriented circuit group blocking message;
c)	respond by a circuit group reset acknowledgement message in which the status indicator bits of the circuits available for service or blocked for reasons of hardware failure are coded 0 and the status indicator bits of all circuits blocked for maintenance reasons are set to 1;
d)	if it had previously received (a) blocking message(s) or (a) circuit group 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 concerning circuits for which a circuit group reset message or reset circuit message(s) have been sent the circuits concerned 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 exchange will then reconstruct its memory according to the possibly received circuit group blocking messages and the received circuit group reset acknowledgement message. It will respond to the possibly received circuit group blocking messages in the normal way.
	If no acknowledgement to a circuit group reset message is received before 4–15 seconds the circuit group reset message should be repeated. If an acknowledgement for the circuit group reset message is not received within 1 minute 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 1 minute intervals until maintenance intervention occurs.
	A correct acknowledgement should match the original circuit group reset message in range and circuit identification code indicated in the routing label. The circuit identification code in the routing label of both circuit group reset messages and circuit group reset acknowledgement messages should belong to a circuit whose control is allocated to the ISDN–UP.
	All circuit identification codes in the range of a circuit group reset and circuit group reset acknowledgement message must belong to circuits whose control is allocated to the ISDN–UP.
2.10.3.3	Abnormal circuit group reset message procedures
i)	If a circuit group reset message is received indicating reset of more circuits than allowed by the receiving exchange, it is discarded.
ii)	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.
iii)	If a circuit group reset message is received requesting reset of circuits that are not controlled by the ISDN user part, or a circuit group reset acknowledgement message that contains circuit identification codes that are not controlled by the ISDN–UP, the message is discarded.
2.10.4	Failure in the blocking/unblocking sequence
	An exchange will repeat the blocking (unblocking) message or the circuit group blocking (unblocking) message on failure to receive the appropriate acknowledgement in response to one of these messages before 4–15 seconds (T12). (See § 2.9.2).
	If the appropriate acknowledgement is not received within a period of one minute (T20) after sending the initial blocking (unblocking) message or group blocking (unblocking) message, the maintenance system should be alerted, the repetition of the blocking (unblocking) message or circuit group blocking (unblocking) message should be continued at one minute intervals until maintenance intervention occurs and the circuit(s) taken out of (returned to) service as appropriate.
2.10.5	Receipt of unreasonable and unrecognized signalling information messages
	The message transfer part of the signalling system will avoid missequencing, or double delivery, of messages with a high reliability (Recommendation Q.706, § 2). However, undetected errors at the signalling link level and exchange malfunctions may produce signalling information messages that are either ambiguous or inappropriate.
	The procedures listed below do not include the procedures for the blocking, circuit group blocking and the circuit group reset; these are covered in §§ 2.9.2.3 and 2.10.3.3 respectively.
2.10.5.1	Handling of unexpected messages
	An unexpected message is one which is recognized and valid 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 (the possibility of maintaining the connection is for further study);
d)	if other unreasonable signalling information is 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;
e)	if unreasonable signalling information caused by conflicting code point values in the protocol control indicator as specified in Recommendation Q.763 is received in a backwards call set–up message, and if the conflicting conditions can be reconciled by assuming lower network capability in the affected parameter, the call should be allowed to continue if the service requirements for the call can be satisfied.
	Except in certain cases (see § 2.10.1) any other unexpected messages received will be discarded. If the discarding of the signalling information prevents a call from being completed, that call will eventually be released by the expiry of a time out.

2.10.5.2	General requirements on receipt of unrecognized signalling information messages and parameters
	Normally an exchange knows the signalling system or version of a signalling system to be used to its adjacent exchanges. However, in certain circumstances (e.g. upgrading of a signalling system in the network) it may happen that an exchange receives unrecognized information, i.e. messages or parameters or parameter values. No distinction is being made between unrecognized and unimplemented functions.
	The procedure to be used on receipt of unrecognized information, may use one of the following messages:
–	confusion,
–	release,
–	release complete,
–	facility reject.
	It should be noted that the use of the confusion message is mainly to facilitate interworking with subsequent issues of the ISDN user part protocol. In these cases the message will include one of the following cause values with a diagnostic field containing either the unrecognized message type code or the unrecognized parameter name code (this information will be returned as soon as possible):
–	unrecognized message,
–	unrecognized parameter passed on (see Note),
–	unrecognized parameter discarded (see Note).
	Note – In a confusion message these parameters are always followed by the parameter name code in the diagnostic field.
	The procedures are based on the following assumptions:
–	Signalling for a facility completely provided between the originating and destination local exchanges will utilise one of the end–to–end methods defined in § 3, i.e. such facilities do not have to be supported by transit exchanges.
–	As a minimum, all implementations must recognize all messages specified in Table 1/Q.764.
–	If an exchange receives a confusion, release, release complete or facility reject message indicating an unrecognized message parameter or parameter value received it assumes interworking with an exchange at a different functional level.
–	Unrecognized parameters only refer to optional parameters since mandatory parameters will always be recognized by their location in a message.
	Action taken on receipt of these messages, will depend on the call state and the affected service. The default action taken on receipt of a confusion message is to discard the message without disrupting normal call processing. In addition, if the cause received indicates discarded information and that information is important, the call may be released with a release message with the cause “normal, unspecified”.
	The actions taken at an intermediate node, e.g. transit exchange on receipt of a confusion message will be dependent on the call state.
	If an intermediate node, e.g. transit exchange, does not have the capability to take action on receipt of a facility reject message, it should pass the message transparently to the preceding or succeeding exchange.
	Action taken on receipt of a release complete message with cause indicating unrecognized information may be as for the normal procedures.
TABLE 1/Q.764
Minimum messages recognized
Address complete	
 Answer	
 Blocking	
 Blocking acknowledgement	
 Call progress	
 Circuit group blocking	
 Circuit group blocking acknowledgement	
 Circuit group reset	
 Circuit group reset acknowledgement	
Circuit group unblocking	
 Circuit group unblocking acknowledgement	
 Connect	
 Continuity	
 Confusion	
 Facility reject	
 Facility request	
 Forward transfer	
 Information	
 Information request	
 Initial address	
 Release	
 Release complete	
 Reset circuit	
 Resume	
 Subsequent address	
 Suspend	
 Unblocking	
 Unblocking acknowledgement	
2.10.5.3	Procedures for the handling of the unrecognized messages or parameters
	A confusion message must not be sent in response to a received confusion message.
a)	Unrecognized mesages
	If an unrecognized message is received at an exchange, the message is discarded and a confusion message returned. The confusion message will include the cause value “unrecognized message” followed by a diagnostic field containing the message type code.
	Note – All messages not included in Table 1/Q.764 may be regarded as unrecognized. As a minimum all implementations must recognize all messages specified in Table 1/Q.764.
b)	Unrecognized parameters
	If an exchange receives and detects an unrecognized parameter the actions taken will be dependent on whether the call can be progressed or not.
	If the call cannot be processed a release message is sent containing the cause “unrecognized parameter discarded” followed by the parameter name code in the diagnostic field.
	If the call can be progressed, the call is processed and the message is sent to the succeeding/preceding exchange. The unrecognized parameter may be either passed on or discarded.
	If the unrecognized parameter is discarded a confusion message is sent to the exchange from which the unrecognized parameter was received. The confusion message contains the cause “unrecognized parameter discarded”.
	If the unrecognized parameter is passed on, a confusion message may be sent to the exchange from which the unrecognized parameter was received.
	If a facility request message is received with unrecognized parameters the message is discarded and a facility reject message is returned including the cause “unrecognized parameter discarded” followed by the parameter name code in the diagnostic field.
	If a release message is received with an unrecognized parameter, a release complete message is returned including the cause “unrecognized parameter passed on” followed by the parameter name code in the diagnostic field.
c)	Unrecognized parameter values
	If an exchange receives and detects a recognized parameter but the contents are unrecognized, then the actions taken are as defined below:
i)	Unrecognized mandatory parameter values
	If an exchange receives and detects an unrecognized mandatory parameter value, the actions taken will be dependent on whether the call can be progressed or not.
	If the call can be progressed, the unrecognized mandatory parameter value shall be passed on unmodified. A confusion message with the cause “unrecognized parameter passed on” is sent to the exchange from which the unrecognized mandatory parameter value was received.
	If the call cannot be progressed or the unrecognized mandatory parameter value cannot be passed unmodified, a release message with the cause “unrecognized parameter discarded” followed by the parameter name in the diagnostic field is returned.
	If a facility request message is received with an unrecognized mandatory parameter value(s) the message is discarded and a facility reject message is returned including the cause “unrecognized parameter discarded” followed by the parameter name code in the diagnostic field.
	If a release message is received with an unrecognized mandatory parameter value, a release complete message is returned including the cause “unrecognized parameter passed on” followed by the parameter name code in the diagnostic field.
ii)	Unrecognized optional parameter values
	If an exchange receives and detects an unrecognized optional parameter value, the actions taken will be dependent on whether the call can be progressed or not.
	If the call can be progressed, the unrecognized optional parameter value may be passed on unmodified or discarded. If the unrecognized optional parameter value has been passed on unmodified, a confusion message with the cause “unrecognized parameter passed on” may be sent to the exchange from which the unrecognized optional parameter value was received. If the unrecognized parameter value has been discarded, a confusion message shall be returned.
	If the call cannot be progressed, a release message with the cause “unrecognized parameter discarded” followed by the parameter name in the diagnostic field shall be returned.
	If a facility request message is received with an unrecognized optional parameter value(s) the message is discarded and a facility reject message is returned including the clause “unrecognized parameter discarded” followed by the parameter name code in the diagnostic field.
	If a release message is received with an unrecognized optional parameter value, a release complete message is returned including the cause “unrecognized parameter passed on” followed by the parameter name code in the diagnostic field.
2.10.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 exchange will retransmit the release message.
	On retransmitting the initial release message, a one minute timer (T5) is started. If no release complete message is received on the expiry of this timer (T5), the exchange shall:
i)	send a reset circuit message;
ii)	alert the maintenance system;

iii)	remove the circuit from service;
iv)	continue the sending of the reset circuit message at 1 minute intervals until maintenance action occurs.
2.10.7	Failure to receive a response to an information request message
	If a response is not received in response to an information request message before timer (T2) expires, the exchange will release the connection and the maintenance system may be informed.
2.10.8	Other failure conditions
2.10.8.1	Inability to release in response to a release message
	If an exchange is unable to return the circuit to the idle condition in response to a release message, it should immediately remove the circuit from service, alert the maintenance system and send the blocking message.
	Upon receipt of the blocking acknowledgement message, the release complete message is sent in acknowledgement of the release message.
2.10.8.2	Call–failure
	The call–failure indication is sent in a release message (§ 2.2) whenever a call attempt fails and other specific signals do not apply. Reception of the release message at any Signlalling System No. 7 exchange will cause the release message to be sent to preceding exchanges. If the signalling does not permit the release message to be sent, the appropriate signal, tone or announcement is sent to preceding exchanges.
2.10.8.3	Abnormal release conditions
	If the conditions for normal release as covered in § 2.3 are not fulfilled, release will take place under the following conditions:
a)	Outgoing international or national controlling exchange
The exchange shall:
–	release all equipment and the connection on failure to meet the conditions for normal release of address and routing information before 20–30 seconds after sending the latest address message;
–	release all equipment and release the connection on failure to receive an answer message within time (T6) specified in Recommendation Q.118 after the receipt of the address complete message.
b)	Incoming international exchange
	An incoming international exchange shall release all equipment and the connection into the national network and send back a release message in the following cases:
–	on failure to receive a continuity message if applicable before 10–15 seconds (T8) after receipt of the initial address message; or
–	on failure to receive a backward signal from a national network (where expected) before 20–30 seconds (T7) after receipt of the latest address message; or
–	on receipt of a release message after an address complete message has been generated.
The procedures for the release message are detailed in § 2.2.2.
c)	Transit exchange
	The exchange shall release all equipment and the connection and send back the release message in the following cases:
–	on failure to receive a continuity message if applicable before 10–15 seconds after receipt of the initial address message; or
–	on failure to meet the conditions for normal release as covered in § 2.3 before 20–30 seconds after sending the latest address message;
The procedures for the release message are detailed in § 2.2.2.

2.10.8.4	If messages are lost during an end–to–end transfer, appropriate actions will be taken according to the type of end–to–end technique being used.
2.10.8.5	For calls involving the SCCP, expiration of the call supervision timer (concerned with call set–up) will result in the SCCP being notified of an error condition.
2.10.9	Temporary Trunk Blocking (TTB) (national use)
	TTB is essentially a means of blocking circuits, for a predetermined period, on a route or part of route, to reduce traffic to an exchange which has invoked load control. Circuits are removed from service on a per circuit basis under delay time out conditions applied by the unaffected exchange.
2.10.10	Temporary trunk blocking before release of call (use of a discrete overload message)
2.10.10.1	Characteristics
	When load control is invoked IAMs associated with non–priority calls received on the circuits concerned are “backed–off” by return of the overload message in response to the IAM. Release of the circuit is then delayed by the unaffected node for a period, e.g. 2 minutes, after which the circuit is cleared by normal release procedures.
	Calls backed–off by overload messages may be processed on alternative routes, if available, by–passing the affected nodes; if not they are released in the backward direction with reason (network) congestion.
	Initial address messages marked as priority are not subject to the overload procedure; they are accepted by the affected node and processed as normal.
	During the overload time–out period the circuit concerned is not available for traffic from the affected node to the unaffected node.
	Recognition of the overload situation does not involve the examination of existing messages for detection of an optional TTB parameter.
2.10.10.2	Procedures
a)	Non priority call set–up to an exchange subject to load control
i)	Actions at originating exchange
	In an originating exchange, calls originating from non–priority class lines will not set the calling party category parameter field to “subscriber with priority” in the outgoing IAM.
ii)	Actions at an intermediate or terminating exchange
	When an IAM is received by an exchange which is subject to load control and the calling party category parameter does not indicate a priority call the IAM is not processed and an overload message is returned to the preceding exchange.
iii)	Actions on receipt of the overload message
	At an originating, or intermediate exchange receipt of the overload message shall cause the following actions:
–	A timer (T overload) is started, provisional value 2 minutes. On expiry of the timer the release procedure shall be initiated of the circuit concerned.
–	The call attempt will be continued on an alternative route if available. If not the call will be released in the backward direction with cause “congestion”.
b)	Priority call set–up to an exchange subject to load control
i)	Actions at originating exchange
	In an originating exchange, calls originating from priority class lines will set the calling party category parameter field to “subscriber with priority” in the outgoing IAM.
ii)	Actions at intermediate or terminating exchange
	At an intermediate or terminating exchange where load control has been invoked, the priority call will override the load control and the call will continue in its attempt to be set up.
2.11	ISDN user part signalling congestion control
2.11.1	General
	On receipt of congestion indication primitives (see also Recommendation Q.704 § 11.2.3) the ISDN user part should reduce traffic load (e.g. call attempts) into the affected direction in several steps.
2.11.2	Procedures
	When the first congestion indication primitive is received by the ISDN user part, the traffic load into the affected direction is reduced by one step. At the same time two timers T29 and T30 are started. During T29 all received congestion indication primitives for the same direction are ignored in order not to reduce traffic too rapidly. Reception of a congestion indication primitive after the expiry of T29, but still during T30, will decrease the traffic load by one more step and restart T29 and T30. This stepwise reduction of the ISDN user part signalling traffic is continued until maximum reduction is obtained by arriving at the last step. If T30 expires (i.e. no congestion indication primitives having been received during the T30 period) traffic will be increased by one step and T30 will be restarted unless full traffic load has been resumed.
	Timers T29 and T30 have the following values:
T29 = 300–600 ms,
T30 = 5–10 s.
	The number of steps of traffic reduction and the type and/or amount of increase/decrease of traffic load at the various steps are considered to be an implementation matter.
2.12	Automatic congestion control
	Automatic Congestion Control (ACC) is used when an exchange is in an overload condition (see also Recommendation Q.542). Two levels of congestion are distinguished, a less severe congestion threshold (congestion level 1) and a more severe congestion threshold (congestion level 2).
	If either of the two congestion thresholds are reached, an automatic congestion level parameter is added to all release messages generated by the exchange. This parameter indicates the level of congestion (congestion level 1 or 2) to the adjacent exchanges. The adjacent exchanges, when receiving a release message containing an automatic congestion level parameter should reduce their traffic to the overload affected exchange.
	If the overloaded exchange returns to a normal traffic load it will cease including automatic congestion level parameters in release messages.
	The adjacent exchanges then, after a predetermined time, automatically return to their normal status.
2.12.1	Receipt of a release message containing an automatic congestion level parameter
	When an exchange receives a release message containing an automatic congestion level parameter the ISDN user part should pass the appropriate information to the signalling system independent network management/overload control function within the exchange. This information consists of the received congestion level information and the circuit identification to which the release message applies.
	ACC actions are applicable only at exchanges adjacent to the congested exchange. Therefore, an exchange that receives a release message containing an automatic congestion level parameter should discard that parameter after notifying the network management/overload control function.
2.12.2	Actions taken during overload
	Whenever an exchange is in an overload state (congestion level 1 or 2), the signalling system independent network management/overload control function will direct the ISDN user part to include an automatic congestion level parameter in every release message transmitted by the exchange.

	The network management/overload control function will indicate which congestion level (1 or 2) to code in the automatic congestion level parameter.
	When the overload condition has ended the network management/overload control function will direct the ISDN user part to cease including automatic congestion level parameters in the transmitted release messages.
2.13	Unequipped circuit identification code message (national option)
	An Unequipped Circuit Identification Code (UCIC) message is sent by an exchange in response to either the reception of an IAM, a CCR, a circuit supervision message, or a circuit group supervision message on which it is unable to act as a consequence of its inability to perform a circuit identification code translation. The sending of the UCIC in response to the reception of other messages with UCIC is for further study.
	If an unequipped circuit identification code message is received for an SS No. 7 circuit which has been seized and an initial address message transmitted, the receiving exchange shall:
1)	remove the indicated circuit from the service and report the circuit to the maintenance system for maintenance action;
2)	re–attempt the call on another circuit providing the rejected attempt was a first attempt. If the rejected attempt was a second attempt, either a release message should be returned, (if the incoming circuit is an SS No. 7) or a recorded announcement connected (if the incoming circuit is conventional).
	If an unequipped circuit identification code message is received in response to the transmission of a circuit supervision message, or a continuity check request message, the circuit should be removed from the service and the circuit reported to the maintenance system for maintenance action.
	An exchange receiving a circuit group supervision message whose CIC in the routing label is unequipped should respond with a UCIC message for the circuit in the label. This in effect is the acknowledgement to the initial message. An exchange receiving a circuit group message where CIC in the routing label is equipped but one or more of the indicated circuits by the range field is unequipped merely responds in the manner that it would have if the circuit were equipped. The unequipped state of the circuit(s) will be recovered when an IAM, a CCR message, or circuit query message is received for the affected circuit(s).
	An exchange receiving an unequipped CIC message after having transmitted a circuit group supervision message removes the indicated circuit from service, assumes the regular acknowledgement message will not be received and treats the other circuits as though the responding exchange had not taken the action on the affected circuits indicated in the initial message.

Figure 1/Q.764 - T1119730-88

Figure 2/Q.764 - T1119740-88

Figure 3/Q.764 - T1119750-88

Notes referring to Figures 1/Q.764 to 3/Q.764
Note 1 – The alerting message may not be given by a called terminal having automatic answer. Under these circumstances the Connect Message will be sent as soon as the Connect Message is received and through–connection of the speech path has been completed.
Note 2 – For telephone calls within the ISDN, ringing tone will be applied by the terminating exchange as soon as it is known that the subscriber is free. In the case of a PABX connected to the access interface there is the option of an early through–connection of the switchpath so that the in–band call arrival indication generated in the PABX is returned to the calling user. For data calls, ringing tone is not applied.
Note 3 – The continuity check may be applicable on an intermediate circuit if analogue circuits are used.
Note 4 – This example assumes that the number length is known at the second transit exchange in order to illustrate the addition of SAMs to the IAM received. This function does not have to be performed in this way.
Note 5 – The call may be rejected by the user at this point following interchanges of user–user data, e.g. as a result of a failed compatibility check.
Note 6 – Charging for the transfer of user–user data requires further study.
Note 7 – Flow control of user–user data is achieved by the originating and destination exchanges by the use of “receive ready” and “receive not ready” messages throughout the conversation/data phase.
Note 8 – Access protocol example is for point–to–point operation only.

Figure 4/Q.764 - T1119760-88

Figure 5/Q.764 - T1119770-88

Figure 6/Q.764 - T1119780-88

Figure 7/Q.764 - T1119790-88

Figure 8/Q.764 - T1119800-88

Figure 9/Q.764 - T1119810-88

Figure 10/Q.764 - T1119820-88