SCCP TCAP Primitives

The communication that takes place between the MTP, SCCP, and TCAP layers of the SS7 stack is achieved with the use of primitives. Interfaces between the functional elements of SS7 are specified using interface primitives. Primitive interface definition does not assume any specific implementation of a service The host uses SCCP/TCAP services by invoking the SCCP N- or TCAP TC- primitives with the PPL Event Request message. A response status of Positive ACK (0x10) indicates that the primitive is validated and processed. A NACK of 0x54 indicates "Error Detected in Primitive". The LSB of the Status byte gives more detail on the error. TC-USER can re-send the corrected primitive. See Response Status Values in the API Reference for details on LSB status.

Dialog primitives request or indicate facilities of transaction sub-layer, in relation with message translation or dialog handling. dialog primitives may contain a TCAP ICB or a TCAP ICB and an SCCP ICB.

Component primitives are used in the handling of operations and replies. They do not require facilities form the underlying sub-layer. Component primitives contain a TCAP ICB.

The maximum number of simultaneous transactions is 32,000 per stack. If number is exceeded, any TC-USER request which may result in a new transaction to be created is returned with a NACK of Resource Limitation (0x5409).

You can use the SS7 SCCP/TCAP Query message (0x0078) to query the number of active dialog/transaction/operations.

• Messages that never get a response back (hanging dialog) - these dialogs use the TCAP dialog resources and do not release them.

The maximum number of simultaneous invocations is 96,000. There is no limit on the number of invocations per transaction. If you include multiple components within one TCAP message, you should ensure that it fits in one MSU, otherwise; you may receive a NACK for the message. (If you use the SCCP Segmentation feature of SCCP/TCAP, this limitation does not apply. The maximum length of a TCAP message can be 3092 (ANSI) or 2048 (ITU).)

Important! In this context, incoming dialog means the new dialog is initialized, caused by receiving a network TCAP message (BEGIN[ITU], or QUERY[ANSI]). Outgoing dialog means the new dialog is initialized, caused by the host sending a TCAP primitive (TC_BEGIN[ITU], or TC_QUERY_ with/without_PERMISSION[ANSI]).

A TC_USER begins a new dialog by issuing a TC-BEGIN (ITU) or TC-QUERY-WITH-PERMISSION/TC-QUERY-WITHOUT-PERMISSION (ANSI) request primitive to:

• indicate to the Component sub-layer that a new dialog starts, identified by the dialog ID parameter.

• request transmission of any component(s) previously passed to the Component sub-layer by means of component handling primitives of the Request type with the same dialog ID.

A TC-USER indicates that it wants to continue a dialog by issuing a TC-CONTINUE (ITU) or TC-CONVERSATION-WITH-PERMISSION/TC-QUERY-WITHOUT-PERMISSION (ANSI) request primitive.

The end of the dialog has been decided by prior arrangement of the TC-USERs. The effect of the TC-END (ITU) or TC-RESPONSE (ANSI) request primitive is local only; no TC-END or TC-RESPONSE indication is generated.

The ending causes transmission of any pending components at the side which initiates it.

The TC-U-ABORT request and indication primitives are used to indicate abort by the TC-USER.

The incoming Dialog ID space is a set including 32,000 continuous dialog IDs (per stack). This is because incoming dialog IDs are allocated by TCAP and the maximum TCAP support is 32,000 simultaneous transactions per stack. The beginning of the incoming dialog ID is defined by the TCAP PPL component TCO Config Byte 1-4 (see TCAP TCO (0x0073). This can be reconfigured, if necessary. The outgoing dialog ID, however, is specified by the TC user. Even though TCAP software does support any 4-byte dialog ID, as long as it does not collide with the incoming ID set, we recommend the use of the range from 0 - 32767 for performance reasons. The dialog ID, which must be four bytes, is also used in the SS7 TCAP Parameters (0x21) ICB which is used with the PPL Event Indication and PPL Event Request API messages.

TC-USERs are notified of non-delivery of components by the TC-NOTICE indication primitive. A TC-NOTICE indication primitive is only passed to the TC-USER if the requested service cannot be provided and the TC-USER requested the Return Option in the Quality of Service parameter of the dialog handling request primitive.

The TC-INVOKE (ITU), TC-INVOKE-L (ANSI) and TC-INVOKE-NL (ANSI) primitives are used to invoke a remote operation.

The TC-RESULT-L and TC-RESULT-NL primitives are used to indicate that an operation has been executed by the remote TC-USER.

A TC-USER receiving an operation which it cannot execute, though it understands it, will issue a TC-U-ERROR request primitive, indicating the reason of the failure (Error parameter). The TC-USER which invoked the operation is informed by a TC-U-ERROR indication primitive.

A TC-USER rejects a component with the TC-U-REJECT request primitive, and is informed of rejection by the remote TC_User with the TC-U-REJECT indication primitive.

Cancel of an Operation: The TC-USER informs the local Component sub-layer of a cancel decision with the TC-U-CANCEL request primitive. No component is sent.

While detecting that a received component is invalid, the Component sub-layer notifies the local TC-USER with the TC-L-REJECT indication primitive. The reject information is passed to the TC-USER and also retained in the Component sub-layer which uses it to form a Reject component.

The remote TC-USER is informed of the received Reject component through a TC-R-REJECT indication primitive.

TCAP may abort the association between users due to an abnormal situation. The structured dialog must then also be aborted. All associated operations are terminated and the TC-USERs are notified with the TC-P-ABORT indication primitive.

An incoming reject component received with a TCAP Problem Code causes a TC-R-REJECT indication to be sent to the TC-USER. This indicates that the remote TCAP detected a problem with a previously sent component.

An incoming reject component received with a TC-USER Problem Code causes a TC-U-REJECT indication to be sent to the TC-USER. This indicates that the remote TC-USER detected a problem with a previously sent component and issued a TC-U-REJECT request.

A TC-L- REJECT indication is used when a local TCAP detects a problem with an incoming component. TCAP sends a TC-L- REJECT indication to the host and a Reject component to the remote TCAP.

When a component is rejected by TCAP, all subsequent components within the same TCAP message are discarded. Any components before the invalid component are sent to the host by the proper primitives.

• TCAP Restart procedures apply for all active subsystems, if the TCAP PPL Component TUSI Config Byte 3 is set as "1".

When the host link is recovered, it is the host’s responsibility to set all subsystems in service using the N_STATE primitive as allowed.

A system reset or switchover will result in a TCAP Restart. All active TCAP dialogs will return to the IDLE state. You can initiate a manual TCAP restart by sending a PPL Event Request message to the TCAP TUSI component with the event of TCAP Restart (0x1E).

Do not reuse the dialog ID immediately after a TCAP Restart as there may be some network messages remaining in queue for the old dialog.

PPL Config Byte 2 of the TCAP TUSI component indicates the Abort Reason sent in the TCAP Abort message following a TCAP Restart.

For primitives in TCAP (e.g., for TCAP TUSI: TC-BEGIN, TC-CONTINUE, TC-UNI) the following applies:

• The maximum ICB length in the PPL Event Indication has a default value of 240.

• When any TC-Primitive exceeds 240, then a TCAP TUSI PPL Event Indication (event=0x1F) is sent to the host prior to the actual PPL Event Indication, which means that the following actual PPL Event Indication is truncated. You can increase this value by using TCAP TUSI Config Bytes 4 and 5. See SS7 PPL Information for the config byte message description.

For the definition and usage of TCAP primitives, refer to the ITU White Book Q.711 "Functional Description of Transaction Capabilities" and Q.775 "Guideline for using TCAP."

This section lists the SCCP and TCAP primitives supported by Dialogic’s SCCP/TCAP feature. Primitives are sent to and received from the CSP in the PPL Event Request and PPL Event Indication messages in ICBs.

Important! SCCP/TCAP primitives should not be confused with Dialogic PPL primitives. TCAP Components should not be confused with Dialogic PPL components. See PPL Information for PPL event values and ICB formats.

The required ICBs with mandatory (M) and optional (O) parameters are shown with each primitive. See SCCP/TCAP Parameter Information for the data required for each parameter.

The ANSI specification does not define TCAP primitives to TC_User. Where common primitives are used, Dialogic followed the ITU Q.771 definitions.

The following ITU SCCP and TCAP primitives are supported by the PPL Event Request and PPL Event Indication messages. The primitive is supported by both messages unless noted otherwise.

The ANSI primitives are supported by both the PPL Event Request and PPL Event Indication message unless noted otherwise.

See Message Transfer Part.

See Transaction Capability Application Part.

See Signaling System Number Seven.

See Programmable Protocol Language.

Positive acknowledgment to a message

Negative acknowledgement to a message.

Least Significant Bit

See Information Control Block.

American National Standards Institute. ANSI administers and coordinates the U.S. voluntary standardization and conformity assessment system for the
telecommunications industry. More details on these standards may be
viewed at www.ansi.org.

International Telecommunications Union (UN)

A condition that, when met, drives a state machine from one state to another. A condition that drives a Component out of its current state by invoking an associated primitive.

A computer, attached to the Excel platform through an RS-232 or Ethernet link, from which you run the telecommunications application that controls the Excel platform.

A programmable software component that uses PPL state machines that can be modified with the PPL Tool.

In PPL, a condition that, when met, drives a state machine (PPL Component) from one state to another, by invoking an associated Primitive. In PPL files, an Event is marked by an arrow and text.

ITU-TSS Publication on Functional Description of SCCP

ITU-TSS Publication on SS7 Test Specification General Description (TCAP)