ISUP:Circuit continuity testing - Revision history

Allyntree: needs revising edit

2018-03-16T18:46:43Z

needs revising edit

← Older revision		Revision as of 13:46, 16 March 2018
Line 1:		Line 1:
	As [[SS7]] signaling is out-of-band compared to the circuits (voice/data channels), there is ~~sometimes the~~ need to validate the integrity of a circuit before using it to establish connections. This is especially true for connections that ~~have to~~ go through a satellite path. There are two methods for initiating a continuity test: ~~within~~ a call or outside a call).		[[SS7]] signaling is out-of-band compared to the circuits (voice/data channels), therefore, at times there is a need to validate the integrity of a circuit before using it to establish connections. This is especially true for connections that go through a satellite path. There are two methods for initiating a continuity test: in a call and outside a call.

	During ~~setup time~~, a circuit is configured with options. These options are used by the [[ISUP]] layer when a remote SS7 node queries information about a circuit and do not affect the behavior of the layer. Three of ~~those~~ options are NONE, STATISTICAL and PER-CALL. When the ~~first option (~~NONE) is used, the host application should not issue any continuity check on the specific circuit. There is no side effect when issuing a continuity check on such a circuit other than not respecting the local node configuration as seen by other SS7 nodes. When the ~~last option is used~~ (PER-CALL), the host application should issue a continuity check for every outgoing call. The ~~remaining option~~ (STATISTICAL) lets the host application decide on a per-call basis if continuity testing should be done.		During the set up, a circuit is configured with options. These options are used by the [[ISUP]] layer when a remote SS7 node queries information about a circuit and does not affect the behavior of the layer. Three of these options are NONE, STATISTICAL and PER-CALL. When the NONE) option is used, the host application should not issue any continuity check on the specific circuit. There is no side effect when issuing a continuity check on such a circuit other than not respecting the local node configuration as seen by other SS7 nodes. When the (PER-CALL) option is used, the host application should issue a continuity check for every outgoing call. The (STATISTICAL) option lets the host application decide on a per-call basis if continuity testing should be done.

	Since the circuit options ~~don’t~~ influence the behavior of the ISUP layer, the three ways to issue continuity checks are to 1) set the ‘fContChkForOutgoing’ field in the circuit configuration structure upon allocation or 2) set the ‘continuity test required’ field of the ‘nature of connection indicators’ [[information element\|IE]] into an outgoing [[IAM]] message or 3) send a [[CCR]] (continuity check request) primitive ~~upon~~ an idle circuit. The ‘fContChkForOutgoing’ should be set to TBX_TRUE when the circuit option CONTINUITY_CHECK_PERCALL is used to be consistent with the configuration. This will instruct the ISUP layer to force the proper IE configuration for every outgoing call.		Since the circuit options do not influence the behavior of the ISUP layer, the three ways to issue continuity checks are to 1) set the ‘fContChkForOutgoing’ field in the circuit configuration structure upon allocation, or 2) set the ‘continuity test required’ field of the ‘nature of connection indicators’ [[information element\|IE]] into an outgoing [[IAM]] message, or 3) send a [[CCR]] (continuity check request) primitive on an idle circuit. The ‘fContChkForOutgoing’ should be set to TBX_TRUE when the circuit option CONTINUITY_CHECK_PERCALL is used to be consistent with the configuration. This will instruct the ISUP layer to force the proper IE configuration for every outgoing call.

	'''NOTE:''' When using configuration parameter fContChkForOutgoing’, the TB640 will enforce the ‘continuity check required’ field in the ‘nature of connection indicators’ IE for every outgoing call. To be consistent, the host application should set the circuit option to CONTINUITY_CHECK_PERCALL.		'''NOTE:''' When using configuration parameter fContChkForOutgoing’, the TB640 will enforce the ‘continuity check required’ field in the ‘nature of connection indicators’ IE for every outgoing call. To be consistent, the host application should set the circuit option to CONTINUITY_CHECK_PERCALL.
Line 9:		Line 9:

	== Continuity testing within a call ==		== Continuity testing within a call ==
	This circuit testing occurs when the forward side (originating side) sets the ‘continuity test required’ field of the ‘nature of connection indicators’ IE into the IAM message. This indicates to the backward end to activate a physical loopback (see note below) on the circuit associated with the call. Then, the forward side can proceed with the circuit testing, usually by sending a test tone and analyzing the returned data. The forward side indicates to the backward side about the result of the test by sending a COT (continuity test report) which will then remove the loopback from the circuit. In case of success, the call can proceed as usual (see call flow 6.3.4.9). If the test fails, the forward side ~~then~~ starts a ‘continuity re-check’ sequence by sending a CCR (continuity check request) (see call flow XXXX). Because the first test fails, it is not recommended to keep the pending call opened and, therefore, the host application should consider it as closed. Upon reception of the CCR, the backward side re-activates the loopback on the circuit and waits for the test report (COT). Again, after analyzing the test data, the forward end sends a report (COT) to the backward end. In case of success, the circuit is returned to the idle state. In case of failure, it is recommended that the host applications (both forward and backward) block the circuit to prevent subsequent calls on the circuit (see call flow 6.3.4.12).		This circuit testing occurs when the forward side (originating side) sets the ‘continuity test required’ field of the ‘nature of connection indicators’ IE into the IAM message. This indicates to the backward end to activate a physical loopback (see note below) on the circuit associated with the call. Then, the forward side can proceed with the circuit testing, usually by sending a test tone and analyzing the returned data. The forward side indicates to the backward side about the result of the test by sending a COT (continuity test report), which will then remove the loopback from the circuit. In case of success, the call can proceed as usual (see call flow 6.3.4.9). If the test fails, the forward side starts a ‘continuity re-check’ sequence by sending a CCR (continuity check request) (see call flow XXXX). Because the first test fails, it is not recommended to keep the pending call opened and, therefore, the host application should consider it as closed. Upon reception of the CCR, the backward side re-activates the loopback on the circuit and waits for the test report (COT). Again, after analyzing the test data, the forward end sends a report (COT) to the backward end. In case of success, the circuit is returned to the idle state. In case of failure, it is recommended that the host applications (both forward and backward) block the circuit to prevent subsequent calls on the circuit (see call flow 6.3.4.12).

	'''NOTE:''' If the backward-end circuit is located on a TB640 blade, there is an easy way to do a trunk resource physical loopback. The application only needs to allocate a full-duplex trunk resource (which should already been done anyway if it plans to receive calls on this specific trunk) and connect it on itself with a half-duplex connection (source connected on destination) using the connection API. To achieve this, use the same hTrunkRes as the source and destination in the TB640_MSG_ID_CONN_OP_CREATE message and set the connection type to half-duplex. No other resource is required.		'''NOTE:''' If the backward-end circuit is located on a TB640 blade, there is an easy way to do a trunk resource physical loopback. The application only needs to allocate a full-duplex trunk resource (which should already been done anyway if it plans to receive calls on this specific trunk) and connect it on itself with a half-duplex connection (source connected on destination) using the connection API. To achieve this, use the same hTrunkRes as the source and destination in the TB640_MSG_ID_CONN_OP_CREATE message and set the connection type to half-duplex. No other resource is required.
Line 16:		Line 16:
	== Continuity testing outside a call==		== Continuity testing outside a call==
	This circuit testing occurs when one of the nodes wants to validate a currently idle circuit. It is recommended that the switch first blocks the circuit to prevent calls to use the circuit during the testing. The testing pattern is similar as for the continuity testing within a call except that the initial testing is indicated by a ‘CCR’ sent by the testing side (instead of being embedded in an IAM primitive). Refer to call flows 6.3.4.14, 6.3.4.15 and 6.3.4.16.		This circuit testing occurs when one of the nodes wants to validate a currently idle circuit. It is recommended that the switch first blocks the circuit to prevent calls to use the circuit during the testing. The testing pattern is similar as for the continuity testing within a call except that the initial testing is indicated by a ‘CCR’ sent by the testing side (instead of being embedded in an IAM primitive). Refer to call flows 6.3.4.14, 6.3.4.15 and 6.3.4.16.


	~~[[category:Needs revising]]~~

Ktrueman: initial content

2009-08-24T21:30:30Z

initial content

New page

As [[SS7]] signaling is out-of-band compared to the circuits (voice/data channels), there is sometimes the need to validate the integrity of a circuit before using it to establish connections. This is especially true for connections that have to go through a satellite path. There are two methods for initiating a continuity test: within a call or outside a call).

During setup time, a circuit is configured with options. These options are used by the [[ISUP]] layer when a remote SS7 node queries information about a circuit and do not affect the behavior of the layer. Three of those options are NONE, STATISTICAL and PER-CALL. When the first option (NONE) is used, the host application should not issue any continuity check on the specific circuit. There is no side effect when issuing a continuity check on such a circuit other than not respecting the local node configuration as seen by other SS7 nodes. When the last option is used (PER-CALL), the host application should issue a continuity check for every outgoing call. The remaining option (STATISTICAL) lets the host application decide on a per-call basis if continuity testing should be done.

Since the circuit options don’t influence the behavior of the ISUP layer, the three ways to issue continuity checks are to 1) set the ‘fContChkForOutgoing’ field in the circuit configuration structure upon allocation or 2) set the ‘continuity test required’ field of the ‘nature of connection indicators’ [[information element|IE]] into an outgoing [[IAM]] message or 3) send a [[CCR]] (continuity check request) primitive upon an idle circuit. The ‘fContChkForOutgoing’ should be set to TBX_TRUE when the circuit option CONTINUITY_CHECK_PERCALL is used to be consistent with the configuration. This will instruct the ISUP layer to force the proper IE configuration for every outgoing call.

'''NOTE:''' When using configuration parameter fContChkForOutgoing’, the TB640 will enforce the ‘continuity check required’ field in the ‘nature of connection indicators’ IE for every outgoing call. To be consistent, the host application should set the circuit option to CONTINUITY_CHECK_PERCALL.

== Continuity testing within a call ==
This circuit testing occurs when the forward side (originating side) sets the ‘continuity test required’ field of the ‘nature of connection indicators’ IE into the IAM message. This indicates to the backward end to activate a physical loopback (see note below) on the circuit associated with the call. Then, the forward side can proceed with the circuit testing, usually by sending a test tone and analyzing the returned data. The forward side indicates to the backward side about the result of the test by sending a COT (continuity test report) which will then remove the loopback from the circuit. In case of success, the call can proceed as usual (see call flow 6.3.4.9). If the test fails, the forward side then starts a ‘continuity re-check’ sequence by sending a CCR (continuity check request) (see call flow XXXX). Because the first test fails, it is not recommended to keep the pending call opened and, therefore, the host application should consider it as closed. Upon reception of the CCR, the backward side re-activates the loopback on the circuit and waits for the test report (COT). Again, after analyzing the test data, the forward end sends a report (COT) to the backward end. In case of success, the circuit is returned to the idle state. In case of failure, it is recommended that the host applications (both forward and backward) block the circuit to prevent subsequent calls on the circuit (see call flow 6.3.4.12).

'''NOTE:''' If the backward-end circuit is located on a TB640 blade, there is an easy way to do a trunk resource physical loopback. The application only needs to allocate a full-duplex trunk resource (which should already been done anyway if it plans to receive calls on this specific trunk) and connect it on itself with a half-duplex connection (source connected on destination) using the connection API. To achieve this, use the same hTrunkRes as the source and destination in the TB640_MSG_ID_CONN_OP_CREATE message and set the connection type to half-duplex. No other resource is required.

== Continuity testing outside a call==
This circuit testing occurs when one of the nodes wants to validate a currently idle circuit. It is recommended that the switch first blocks the circuit to prevent calls to use the circuit during the testing. The testing pattern is similar as for the continuity testing within a call except that the initial testing is indicated by a ‘CCR’ sent by the testing side (instead of being embedded in an IAM primitive). Refer to call flows 6.3.4.14, 6.3.4.15 and 6.3.4.16.

[[category:Needs revising]]