TCAP (Transaction Capabilities Application Part, ITU-T Q.771–Q.775) trägt nicht-leitungsbezogene Operationen wie MAP über SCCP. Es hat zwei Sublayer: Der Transaktions-Sublayer korreliert einen Dialog zwischen zwei Knoten mit Begin/Continue/End/Abort-Nachrichten und Transaction-IDs, und der Komponenten-Sublayer trägt die einzelnen Operationen als Invoke, ReturnResult, ReturnError und Reject.
Transaktions-Sublayer
Der Transaktions-Sublayer verwaltet den Ende-zu-Ende-Dialog zwischen zwei TCAP-Gegenstellen. Jede Seite vergibt eine Transaction-ID (die Originating und Destination Transaction ID), sodass mehrere gleichzeitige Dialoge über denselben SCCP-Pfad unterscheidbar bleiben. Ein Dialog wird durch vier Nachrichtentypen eröffnet, fortgesetzt und geschlossen. Ein Austausch mit einer einzelnen Operation kann sogar auf ein Begin+End-Paar verdichtet werden, wenn keine weitere Interaktion nötig ist.
| Nachricht | Zweck |
|---|---|
| TC-BEGIN | Öffnet einen Dialog; enthält die Originating Transaction ID |
| TC-CONTINUE | Setzt einen offenen Dialog in beide Richtungen fort (beide TIDs vorhanden) |
| TC-END | Schließt den Dialog, optional mit der letzten Komponente |
| TC-ABORT | Abnormale Beendigung (Abbruch durch Benutzer oder Anbieter) |
| TC-UNI | Unidirektional – ein strukturierter Dialog ist nicht erforderlich |
Dialog-Anteil und Application Context
Ein optionaler Dialog-Anteil handelt den Application Context aus — einen Object Identifier, der die Anwendung und Version benennt, die beide Gegenstellen sprechen, zum Beispiel den MAP-shortMsgGatewayContext für SMS-Routing oder eine bestimmte MAP-Version für UpdateLocation. Er trägt zudem Benutzerinformationen und, bei ABORT, den Abbruchgrund. Die Einigung auf den Application Context ist, wie ein Empfänger erkennt, welche MAP-Operationen und Parameter innerhalb des Dialogs zu erwarten sind.
Komponenten-Sublayer
Der Komponenten-Sublayer trägt die eigentlichen Operationen. Eine Invoke-Komponente fordert eine Operation an, identifiziert durch eine Invoke-ID und einen Operation Code (den MAP-Opcode), mit den Argumenten der Operation. Die Gegenstelle antwortet mit ReturnResult (Last oder Not Last, bei segmentierten Ergebnissen), ReturnError (ein Anwendungsfehler wie absentSubscriber) oder Reject (ein Protokollproblem wie eine unerkannte Operation). Mehrere Komponenten können in einer einzigen Transaktionsnachricht reisen, und die Invoke-ID verknüpft jede Antwort mit ihrem Request — ganz wie die sequence_number von SMPP.
| Komponente | Bedeutung |
|---|---|
| Invoke | Eine Operation anfordern (Invoke ID + Operationscode + Argumente) |
| ReturnResult (Last) | Endgültiges erfolgreiches Ergebnis einer aufgerufenen Operation |
| ReturnResult (Not Last) | Ein nicht abschließendes Segment eines großen Ergebnisses |
| ReturnError | Der Vorgang ist aufgrund eines Anwendungsfehlers fehlgeschlagen (Fehlercode + Parameter) |
| Reject | Protokollproblem – fehlerhafte, unerwartete oder nicht erkannte Komponente |
Ein MAP-Dialog über TCAP
Eine typische MAP-Abfrage ist ein TCAP-Dialog. Der Initiator sendet TC-BEGIN mit einem Invoke für die MAP-Operation; der Antwortende erwidert TC-END mit einem ReturnResult (oder ReturnError). Längere Gespräche — bei denen die beiden Seiten mehrere Operationen austauschen — nutzen dazwischen TC-CONTINUE. Die Transaction-IDs und Invoke-IDs zusammen lassen einen ausgelasteten Knoten Tausende Dialoge und ihre ausstehenden Operationen auseinanderhalten.
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}Häufig gestellte Fragen
Was ist der Unterschied zwischen dem Transaktions- und dem Komponenten-Sublayer?
Der Transaktions-Sublayer verwaltet den Dialog als Ganzes — Eröffnen, Fortsetzen und Schließen mit Begin/Continue/End/Abort und Transaction-IDs. Der Komponenten-Sublayer trägt die einzelnen Operationen innerhalb dieses Dialogs als Invoke, ReturnResult, ReturnError und Reject.
Was ist eine Invoke-ID in TCAP?
Die Invoke-ID ist eine kleine Kennung, die der Initiator jeder Invoke-Komponente zuweist, sodass das zugehörige ReturnResult oder ReturnError dem Request zugeordnet werden kann. Sie begrenzt Antworten auf einen einzelnen Dialog, ähnlich einer Request/Response-Korrelations-ID.
Was ist ein TCAP-Application-Context?
Der Application Context ist ein Object Identifier im Dialog-Anteil, der benennt, welche Anwendung und Version beide Gegenstellen verwenden — zum Beispiel einen bestimmten MAP-Context für SMS-Routing. Er teilt dem Empfänger mit, welche Operationen und Parameterformate im Dialog zu erwarten sind.
Was ist der Unterschied zwischen ReturnError und Reject?
ReturnError meldet einen Fehler auf Anwendungsebene einer verstandenen Operation — zum Beispiel MAP absentSubscriber. Reject meldet ein Problem auf Protokollebene, etwa einen unerkannten Operation Code oder eine schlecht strukturierte Komponente, und wird von TCAP selbst statt von der Anwendung erzeugt.
Kann eine TCAP-Nachricht mehrere Operationen tragen?
Ja. Eine einzelne Transaktionsnachricht kann mehrere Komponenten tragen, sodass ein Knoten mehrere Invokes bündeln oder mehrere Ergebnisse in einem Begin/Continue/End zurückgeben kann. Jede wird durch ihre Invoke-ID unterschieden, und Ergebnisse können mit ReturnResult Not Last segmentiert werden.
Quellenspezifikationen
Diese Seite basiert auf den veröffentlichten Standards. (Wird in einem neuen Tab geöffnet.)