TCAP (Transaction Capabilities Application Part, ITU-T Q.771–Q.775) trasporta su SCCP operazioni non di circuito come MAP. Ha due sublayer: il transaction sublayer correla un dialogo tra due nodi con messaggi Begin/Continue/End/Abort e transaction ID, e il component sublayer trasporta le singole operazioni come componenti Invoke, ReturnResult, ReturnError e Reject.
Transaction sublayer
Il transaction sublayer gestisce il dialogo end-to-end tra due peer TCAP. Ciascun lato alloca un transaction ID (l'Originating e il Destination Transaction ID) affinché più dialoghi concorrenti sullo stesso percorso SCCP restino distinti. Un dialogo viene aperto, continuato e chiuso da quattro tipi di messaggio. Uno scambio a operazione singola può persino essere compresso in una coppia Begin+End quando non serve ulteriore interazione.
| Messaggio | Scopo |
|---|---|
| TC-BEGIN | Apre un dialogo; contiene l'Originating Transaction ID |
| TC-CONTINUE | Continuare un dialogo aperto in entrambe le direzioni (entrambi i TID presenti) |
| TC-END | Chiude il dialogo, facoltativamente con il componente finale |
| TC-ABORT | Terminazione anomala (interruzione da parte dell'utente o del fornitore) |
| TC-UNI | Unidirezionale: non è richiesto un dialogo strutturato |
Dialogue portion e application context
Una dialogue portion opzionale negozia l'application context — un object identifier che nomina l'applicazione e la versione che entrambi i peer parleranno, ad esempio il MAP shortMsgGatewayContext per l'instradamento SMS o una specifica versione MAP per UpdateLocation. Trasporta anche informazioni utente e, in caso di ABORT, il motivo dell'abort. Concordare l'application context è il modo in cui un ricevente sa quali operazioni e parametri MAP aspettarsi all'interno del dialogo.
Component sublayer
Il component sublayer trasporta le operazioni effettive. Un componente Invoke richiede un'operazione, identificata da un Invoke ID e da un operation code (l'opcode MAP), con i relativi argomenti. Il peer risponde con ReturnResult (Last o Not Last, per risultati segmentati), ReturnError (un errore applicativo come absentSubscriber) o Reject (un problema a livello di protocollo come un'operazione non riconosciuta). Più componenti possono viaggiare in un unico messaggio di transazione e l'Invoke ID collega ogni risposta alla sua richiesta — molto come il sequence_number di SMPP.
| Componente | Significato |
|---|---|
| Invoke | Richiedi un'operazione (Invoke ID + codice operazione + argomenti) |
| ReturnResult (Last) | Risultato finale positivo di un'operazione invocata |
| ReturnResult (Not Last) | Un segmento non finale di un risultato ampio |
| ReturnError | Operazione non riuscita a causa di un errore dell'applicazione (codice di errore + parametro) |
| Reject | Problema di protocollo: componente malformato, inatteso o non riconosciuto |
Un dialogo MAP su TCAP
Una tipica query MAP è un unico dialogo TCAP. L'iniziatore invia un TC-BEGIN che trasporta un Invoke per l'operazione MAP; il rispondente risponde con un TC-END che trasporta un ReturnResult (o un ReturnError). Le conversazioni più lunghe — in cui i due lati scambiano più operazioni — usano TC-CONTINUE nel mezzo. I transaction ID e gli Invoke ID insieme consentono a un nodo trafficato di gestire migliaia di dialoghi e le relative operazioni pendenti.
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}Domande frequenti
Qual è la differenza tra transaction e component sublayer?
Il transaction sublayer gestisce il dialogo nel suo complesso — aprendolo, continuandolo e chiudendolo con Begin/Continue/End/Abort e transaction ID. Il component sublayer trasporta le singole operazioni all'interno di quel dialogo come componenti Invoke, ReturnResult, ReturnError e Reject.
Che cos'è un Invoke ID in TCAP?
L'Invoke ID è un piccolo identificatore che l'iniziatore assegna a ciascun componente Invoke affinché il ReturnResult o ReturnError corrispondente possa essere ricollegato alla richiesta. Delimita le risposte all'interno di un singolo dialogo, come un id di correlazione richiesta/risposta.
Che cos'è un application context TCAP?
L'application context è un object identifier nella dialogue portion che nomina quale applicazione e versione entrambi i peer usano — ad esempio uno specifico context MAP per l'instradamento SMS. Comunica al ricevente quali operazioni e formati di parametro aspettarsi nel dialogo.
Qual è la differenza tra ReturnError e Reject?
ReturnError segnala un fallimento a livello applicativo di un'operazione che è stata compresa — ad esempio MAP absentSubscriber. Reject segnala un problema a livello di protocollo, come un operation code non riconosciuto o un componente mal strutturato, ed è generato da TCAP stesso anziché dall'applicazione.
Un messaggio TCAP può trasportare più operazioni?
Sì. Un singolo messaggio di transazione può trasportare più componenti, quindi un nodo può raggruppare più Invoke o restituire più risultati in un unico Begin/Continue/End. Ciascuno è distinto dal suo Invoke ID e i risultati possono essere segmentati con ReturnResult Not Last.
Specifiche della fonte
Gli standard pubblicati su cui si basa questa pagina. Si apre in una nuova scheda.