Correlating ISUP and TCAP Transactions in SS7 Networks

Reliable signalling analysis depends on knowing which identifiers describe a call and which describe an application transaction. ISUP Call Reference Numbers and TCAP dialogue IDs can appear in the same trace, yet they belong to different protocol layers and follow different lifecycles.

An ISUP reference is tied to circuit-switched call control, while a TCAP dialogue identifier follows an exchange between applications such as mobile location services, number portability, prepaid charging, or database queries. Correlation becomes useful when these activities must be examined as one service event.

For Australian carriers and network engineers, this matters across PSTN interconnects, mobile core networks, international gateways, and IP-based SIGTRAN links. A call from a Melbourne CBD handset to a number in regional Queensland may cross several signalling points before an associated database transaction is completed.

Identifier	Protocol layer	Main purpose	Typical lifetime	Best correlation fields
ISUP Call Reference Number	ISUP over MTP3 or SIGTRAN	Identifies a call leg or circuit-related transaction	Call setup through release	OPC, DPC, CIC, message type, direction
TCAP dialogue ID	TCAP over SCCP	Identifies an application dialogue	Begin through End, Continue, or Abort	SCCP addresses, transaction portions, operation code
CIC	ISUP circuit assignment	Identifies a bearer circuit on a route	Allocated call interval	OPC, DPC, trunk group, CIC
SCCP local or remote transaction ID	TCAP transaction layer	Identifies a TCAP transaction end	Dialogue lifetime	Point codes, subsystem numbers, direction

What each identifier actually represents

The ISUP Call Reference Number, often shown as a call reference or call identity in vendor traces, belongs to the ISUP call-control context. It helps distinguish signalling activity associated with a particular call leg. Engineers should interpret it alongside the Circuit Identification Code, originating and destination point codes, message direction, and the sequence of IAM, ACM, ANM, REL, and RLC messages.

A TCAP dialogue ID is different. TCAP uses transaction identifiers to link messages belonging to an application dialogue. A SendRoutingInfo exchange, for example, may begin with a Begin message and finish with an End message, while a longer service interaction can contain Continue messages. The dialogue ID identifies that transaction, not the voice bearer itself.

This distinction is important when a trace contains reused or locally significant values. An ISUP reference may be unique only within a signalling point, linkset, or call context. A TCAP transaction ID can have separate local and remote values, with each side assigning its own identifier. Treating either value as globally unique produces false matches.

Building a dependable correlation key

A practical correlation key combines identifiers with network context. For ISUP, use the Call Reference Number with OPC, DPC, CIC, signalling direction, and a tight timestamp window. For TCAP, include the local and remote transaction IDs, SCCP calling and called party addresses, global title translation result, subsystem number, and operation type.

The timestamp window should reflect real network behaviour rather than an arbitrary fixed value. A query triggered during call setup may appear within milliseconds, while congestion, retransmission, or an overseas hop can introduce a longer delay. On an Australian national network, traffic between Sydney and Perth may also cross different transport paths and monitoring points.

Correlation engines should preserve message direction. An IAM arriving at a gateway and a related TCAP Begin leaving that gateway are easier to match when the engine understands the node’s role. Direction errors can make a response look like a new request, especially when point codes are translated across an STP or SIGTRAN signalling gateway.

Linking a call leg to a TCAP dialogue

The link between ISUP and TCAP is usually indirect. A service node, mobile switching centre, or gateway may inspect the call context and launch a TCAP query. The trace may therefore contain common evidence such as a calling party number, called party number, nature of address, service key, or translated routing result.

For example, an originating call can produce an ISUP IAM followed by a TCAP query to obtain routing information. The query may return a translated destination, after which the network sends a new ISUP IAM towards another exchange. The original and onward call legs may have different point codes, CICs, and Call Reference Numbers even though they belong to the same customer event.

Number portability makes this especially relevant in Australia, where customers commonly move between Telstra, Optus, and Vodafone services. A portability lookup can explain why the TCAP transaction points towards a database service while the ISUP call continues through a separate inter-carrier route.

Timing, timers, and retransmissions

Correlation should account for protocol timers. ISUP uses timers around call setup, continuity checks, release, and other procedures. TCAP and SCCP have their own transaction and connection-management behaviours. A delayed response can therefore arrive after an analyst’s initial search window has closed.

Duplicate messages require careful handling. A retransmitted TCAP component should not be mistaken for a second customer request, and a repeated ISUP message should be evaluated against sequence, timer, and circuit state. Store message hashes, transport sequence details, and capture-point metadata where possible.

SIGTRAN adds another layer of timing evidence. M2PA, M2UA, or M3UA transport can carry SS7 user parts over IP, with SCTP association resets, ASP state changes, and load-sharing decisions affecting packet visibility. Engineers reviewing a busy national network can find the same event at an STP, signalling gateway, and application node with different capture timestamps.

Common failures in Australian deployments

A frequent mistake is matching only on the numeric identifier. This fails when values are allocated per node or reused after release. Another is joining records solely by calling party number, which can be absent, screened, translated, or formatted differently between ISUP and TCAP.

Capture placement also affects results. A trace from a Brisbane STP may show an SCCP global title before translation, while a service platform in Sydney sees a translated point code and subsystem number. If the correlation platform does not retain both views, the TCAP dialogue may appear unrelated to the originating call.

Operational realities matter too. A service affecting customers in the bush may traverse long-haul links with different latency and congestion characteristics from a Sydney or Melbourne CBD route. During an incident involving emergency 000 traffic, analysts need a defensible relationship between call legs, database lookups, and release causes rather than a guess based on one reused number.

Making correlation useful for operations

A good monitoring model stores the protocol layers separately and joins them through evidence. Keep ISUP call state, CIC occupancy, TCAP dialogue state, SCCP routing data, and SIGTRAN transport health in distinct records. Then expose a combined incident view that shows the confidence and fields used for each match.

Training teams can reinforce this method through structured protocol exercises and carrier-scale examples; the SS7 training products provide a suitable starting point for reviewing ISUP, MTP3, timers, and related signalling concepts. Analysts should practise with both successful and failed calls, including absent responses, aborted dialogues, circuit blocking, and number portability lookups.

Capacity planning supports the same investigation. A national signalling design must account for busy-hour transaction volume, link utilisation, redundancy, and Erlang B assumptions; the Erlang B dimensioning guide can help connect correlation work with signalling-link engineering.

A repeatable workflow for engineers

Start with the ISUP event and record the Call Reference Number, CIC, OPC, DPC, message direction, and call-state timestamps. Next, search for related SCCP traffic using called and calling addresses, subsystem numbers, global title information, and the service operation likely to have been invoked.

Then reconstruct the TCAP dialogue from Begin, Continue, End, or Abort messages, retaining both local and remote transaction identifiers. Compare the application timestamps with ISUP state transitions and mark the relationship as confirmed, probable, or uncorrelated. This confidence label prevents uncertain matches from being treated as facts.

For a practical next step, take one captured IAM and build a correlation record containing its ISUP fields, associated SCCP addresses, TCAP transaction IDs, operation code, and final call outcome.