TCAP Solution Overview

This section provides details that you may want to skip during your first read-though, because a number of PCE concepts have not been fully introduced. The section is intended for users who have a complete understanding about PCE concepts, provisioning, and behavior.

Lifespan of a Transaction ID

PCE records the TCAP transaction ID in a TID database for each new query, but does not keep this ID indefinitely. The TID record is usually removed when the associated transaction is completed. If the transaction is not terminated properly or on time, the transaction ID record is deleted automatically after the TCAP Transaction Timeout (refer to TCAP Configuration) expires. This process ensures that the database size is controlled.

New Transaction ID

The transaction ID sent by the PCE does not match the transaction ID originally sent by the switches. This conversion is required due to a small chance that two switches in the same network use the same transaction ID in the same time frame. This scenario must be avoided. Also, a new transaction ID helps the PCE to determine which PCE process database owns the TID record by using the modulo generator (see the following section, Transaction Routed to Peer).

Transaction Routed to Peer

After a query is sent to the other network, there is no guarantee of its return path. PCE is typically deployed over a mated pair of STPs. Therefore, it is likely that the response message is routed to a different PCE process than the PCE process that originated the query message and has the associated TID record.

In this scenario, the receiving PCE process determines the originating PCE process from the transaction ID. The PCE TID unique values are generated using a modulo incrementation based on the PCE process’ LDL identifier. Therefore, responses do not have to be broadcast to all PCE process, but can be sent directly to the relevant PCE process.

The PCE is a robust system, however, a transaction can be lost if a system that includes PCE is powered off or is otherwise isolated. Typically, there is an automated retransmit by the switch that is generating the TCAP transaction to guard against such a failure.

Multi-step Transactions

Some TCAP transactions have a number of messages that are transmitted back and forth between switches beyond the simple query and response. In addition to query messages, the transaction IDs of the TCAP Continue (ITU) and Conversation With or Without Permission (ANSI) messages are also recorded and linked to their query TIDs as associated TIDs. Depending on transaction termination direction, either the query TID or the associated TID is used to end both transactions.

SCCP Management Messages

PCE does not pass SCCP management messages between networks. These messages are processed locally.

If an SST is received at SCCP, this application responds with an SSA if the affected PC is registered (full SSN range). PCE does not query the other network for the actual state of the SSN.

TCAP Responses from Unknown Sources

It is possible for a private STP to query a public switch, but have the response returned by a different and previously unknown public switch.

Because PCE must register with a known PC to transmit messages to the private network, you can use the Default Private OPC attribute in the TCAP Configuration screen (refer to TCAP Configuration) to ensure that the messages are forwarded as required.

Multi-step TCAP transactions with previously unknown destinations are not possible, because there is no return path for the message. To do multi-step TCAP transactions, the relevant public node(s) must be provisioned.