SCCP TCAP Primitives

Overview

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.

Figure 6-6 Peer-to-Peer Messages

TCAP Primitive Types

There are two types of TCAP primitives:

Dialog

Component

Dialog Primitives

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 Primitive

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.

Dialogs

Simultaneous Transactions

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.

The following may result in a larger number of active dialogs at one time:

Average life time of a dialog is long.

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]).

 

Beginning a dialog

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.

 

Continuing a dialog

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.

 

Ending a dialog

There are three methods for ending a dialog:

• Pre-arranged End

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.

• Basic End

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

• Abort by TC-USER

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

Dialog ID Usage

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.

Exception Reporting and Message Return

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.

 

Invoke a Remote Operation

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

TC-INVOKE-LAST (ANSI)

Indicates the only or last segment of the invocation.

TC-INVOKE-NOT LAST (ANSI)

Indicates a segment of an invocation (with more segments to follow).

 

Report of Success

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

TC-RESULT-L

Indicates the only or last segment of a result.

TC-RESULT-NL

Indicates a segment of a result (with more segments to follow).

 

Report of Failure

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.

 

Reject by TC-USER

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.

 

Reject of a Component by the Component Sub-Layer

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.

 

Dialog Abort

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.

 

Closing a Transaction

A transaction is closed if TC-USER:

Issues:

TC-END (ITU) or TC-RESPONSE (ANSI)

TC-U-ABORT

Receives:

TC-END (ITU) or TC-RESPONSE (ANSI)

TC-U-ABORT

TC-P-ABORT

 

Incoming Reject Components

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.

 

Host Link Failure Handling

When host link failure is detected by the CSP:

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

All local subsystems are set as Prohibited.

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.

 

TCAP Restart

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.

Notes on TCAP Primitives

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."

Supported Primitives

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.

ITU Primitives

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.

TCAP

TC-BEGIN 0x01

TC-CONTINUE 0x02

TC-END 0x03

TC-UNI 0x04

TC-U-ABORT 0x05

TC-P-ABORT 0x06 (Indication only)

TC-RESULT-L 0x0C

TC-RESULT-NL 0x0D

TC-U-ERROR 0x0E

TC-L-CANCEL 0x0F (Indication only)

TC-U-REJECT (0x12)

TC-L-REJECT 0x13 (Indication only)

TC-R-REJECT 0x14 (Indication only)

TC-INVOKE 0x15

TC-U-CANCEL 0x16 (Request only)

TC-NOTICE 0x17 (Indication only)

TC_RESET_TIMER 0x19 (Request only)

SCCP

N-UNIT-DATA 0x01

N-NOTICE 0x02 (Indication only)

N-STATE 0x03

N-PC-STATE 0x04 (Indication only)

ANSI Primitives

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

TCAP

TC-UNI 0x04

TC-U-ABORT 0x05

TC-P-ABORT 0x06 (Indication only)

TC-QUERY-WITH-PERMISSION 0x07

TC-QUERY-WITHOUT-PERMISSION 0x08

TC-CONVERSATION-WITH-PERMISSION 0x09

TC-CONVERSATION-WITHOUT-PERMISSION 0x0A

TC-RESPONSE 0x0B

TC-RESULT-L 0x0C

TC-RESULT-NL 0x0D

TC-U-ERROR 0x0E

TC-INVOKE-L 0x10

TC-INVOKE-NL 0x11

TC-U-REJECT 0x12

TC-L-REJECT 0x13 (Indication only)

TC-R-REJECT 0x14 (Indication only)

TC-U-CANCEL 0x16 (Request only)

TC-NOTICE 0x17 (Indication only)

SCCP

N-UNIT-DATA 0x01

N-NOTICE 0x02 (Indication only)

N-STATE 0x03

N-PC-STATE 0x04 (Indication only)