TCAP (Transaction Capabilities Application Part, ITU-T Q.771–Q.775) carries non-circuit operations like MAP over SCCP. It has two sublayers: the transaction sublayer correlates a dialogue between two nodes with Begin/Continue/End/Abort messages and transaction IDs, and the component sublayer carries the individual operations as Invoke, ReturnResult, ReturnError and Reject components.
Transaction sublayer
The transaction sublayer manages the end-to-end dialogue between two TCAP peers. Each side allocates a transaction ID (the Originating and Destination Transaction IDs) so multiple concurrent dialogues over the same SCCP path stay distinct. A dialogue is opened, continued and closed by four message types. A single-operation exchange can even be compressed into one Begin+End pair when no further interaction is needed.
| Message | Purpose |
|---|---|
| TC-BEGIN | Open a dialogue; carries Originating Transaction ID |
| TC-CONTINUE | Continue an open dialogue in either direction (both TIDs present) |
| TC-END | Close the dialogue, optionally carrying the final component |
| TC-ABORT | Abnormal termination (user abort or provider abort) |
| TC-UNI | Unidirectional — a structured dialogue is not required |
Dialogue portion and application context
An optional dialogue portion negotiates the application context — an object identifier that names the application and version both peers will speak, for example the MAP shortMsgGatewayContext for SMS routing or a specific MAP version for UpdateLocation. It also carries user information and, on ABORT, the abort reason. Agreeing the application context is how a receiver knows which MAP operations and parameters to expect within the dialogue.
Component sublayer
The component sublayer carries the actual operations. An Invoke component requests an operation, identified by an Invoke ID and an operation code (the MAP opcode), with the operation's arguments. The peer responds with ReturnResult (Last or Not Last, for segmented results), ReturnError (an application error such as absentSubscriber), or Reject (a protocol-level problem such as an unrecognised operation). Multiple components can travel in a single transaction message, and the Invoke ID links each response to its request — much like SMPP's sequence_number.
| Component | Meaning |
|---|---|
| Invoke | Request an operation (Invoke ID + operation code + arguments) |
| ReturnResult (Last) | Final successful result of an invoked operation |
| ReturnResult (Not Last) | A non-final segment of a large result |
| ReturnError | Operation failed with an application error (error code + parameter) |
| Reject | Protocol problem — malformed, unexpected or unrecognised component |
A MAP dialogue over TCAP
A typical MAP query is one TCAP dialogue. The initiator sends TC-BEGIN carrying an Invoke for the MAP operation; the responder answers TC-END carrying a ReturnResult (or ReturnError). Longer conversations — where the two sides exchange several operations — use TC-CONTINUE in between. The transaction IDs and Invoke IDs together let a busy node keep thousands of dialogues and their pending operations straight.
SMSC → HLR TC-BEGIN OTID=0x1A2B
Invoke invokeID=1 opCode=sendRoutingInfoForSM(45)
{msisdn, sm-RP-PRI, serviceCentreAddress}
HLR → SMSC TC-END DTID=0x1A2B
ReturnResultLast invokeID=1
{imsi, locationInfoWithLMSI: MSC address}Frequently asked
What is the difference between the transaction and component sublayers?
The transaction sublayer manages the dialogue as a whole — opening, continuing and closing it with Begin/Continue/End/Abort and transaction IDs. The component sublayer carries the individual operations inside that dialogue as Invoke, ReturnResult, ReturnError and Reject components.
What is an Invoke ID in TCAP?
The Invoke ID is a small identifier the initiator assigns to each Invoke component so the corresponding ReturnResult or ReturnError can be matched back to the request. It scopes responses within a single dialogue, similar to a request/response correlation id.
What is a TCAP application context?
The application context is an object identifier in the dialogue portion that names which application and version both peers use — for example a specific MAP context for SMS routing. It tells the receiver which operations and parameter formats to expect in the dialogue.
What is the difference between ReturnError and Reject?
ReturnError reports an application-level failure of an operation that was understood — for example MAP absentSubscriber. Reject reports a protocol-level problem, such as an unrecognised operation code or a badly structured component, and is generated by TCAP itself rather than the application.
Can one TCAP message carry several operations?
Yes. A single transaction message can carry multiple components, so a node can bundle several Invokes or return several results in one Begin/Continue/End. Each is distinguished by its Invoke ID, and results can be segmented with ReturnResult Not Last.
Source specifications
The published standards this page is grounded in. Opens in a new tab.