Le TCAP (Transaction Capabilities Application Part, ITU-T Q.771–Q.775) porte des opérations hors circuit comme MAP sur SCCP. Il comporte deux sous-couches : la sous-couche transaction corrèle un dialogue entre deux nœuds avec des messages Begin/Continue/End/Abort et des identifiants de transaction, et la sous-couche composant porte les opérations individuelles sous forme de composants Invoke, ReturnResult, ReturnError et Reject.
Sous-couche transaction
La sous-couche transaction gère le dialogue de bout en bout entre deux pairs TCAP. Chaque côté alloue un identifiant de transaction (les Originating et Destination Transaction IDs) pour que plusieurs dialogues simultanés sur le même chemin SCCP restent distincts. Un dialogue est ouvert, poursuivi et clos par quatre types de message. Un échange à opération unique peut même se comprimer en une seule paire Begin+End quand aucune interaction supplémentaire n'est nécessaire.
| Message | Objectif |
|---|---|
| TC-BEGIN | Ouvrir un dialogue ; transporte l'Originating Transaction ID |
| TC-CONTINUE | Poursuivre un dialogue ouvert dans les deux sens (les deux TID sont présents) |
| TC-END | Fermer le dialogue, en transportant éventuellement le composant final |
| TC-ABORT | Arrêt anormal (abandon par l'utilisateur ou par le fournisseur) |
| TC-UNI | Unidirectionnel — un dialogue structuré n'est pas nécessaire |
Portion dialogue et contexte applicatif
Une portion dialogue optionnelle négocie le contexte applicatif — un identifiant d'objet qui nomme l'application et la version que les deux pairs vont parler, par exemple le MAP shortMsgGatewayContext pour le routage SMS ou une version MAP précise pour UpdateLocation. Elle porte aussi des informations utilisateur et, sur ABORT, la raison de l'abandon. Convenir du contexte applicatif est la façon dont un récepteur sait quelles opérations et paramètres MAP attendre dans le dialogue.
Sous-couche composant
La sous-couche composant porte les opérations réelles. Un composant Invoke demande une opération, identifiée par un Invoke ID et un code d'opération (l'opcode MAP), avec les arguments de l'opération. Le pair répond par ReturnResult (Last ou Not Last, pour les résultats segmentés), ReturnError (une erreur applicative telle qu'absentSubscriber), ou Reject (un problème protocolaire tel qu'une opération non reconnue). Plusieurs composants peuvent voyager dans un même message de transaction, et l'Invoke ID relie chaque réponse à sa requête — à la manière du sequence_number du SMPP.
| Composant | Signification |
|---|---|
| Invoke | Demander une opération (Invoke ID + code d'opération + arguments) |
| ReturnResult (Last) | Résultat final réussi d'une opération invoquée |
| ReturnResult (Not Last) | Un segment non final d'un résultat volumineux |
| ReturnError | L'opération a échoué en raison d'une erreur d'application (code d'erreur + paramètre) |
| Reject | Problème de protocole — composant malformé, inattendu ou non reconnu |
Un dialogue MAP sur TCAP
Une requête MAP typique est un dialogue TCAP. L'initiateur envoie un TC-BEGIN portant un Invoke pour l'opération MAP ; le répondeur répond par un TC-END portant un ReturnResult (ou ReturnError). Les conversations plus longues — où les deux côtés échangent plusieurs opérations — utilisent des TC-CONTINUE entre les deux. Les identifiants de transaction et les Invoke ID permettent ensemble à un nœud chargé de gérer clairement des milliers de dialogues et leurs opérations en cours.
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}Questions fréquemment posées
Quelle différence entre les sous-couches transaction et composant ?
La sous-couche transaction gère le dialogue dans son ensemble — l'ouvrant, le poursuivant et le clôturant avec Begin/Continue/End/Abort et des identifiants de transaction. La sous-couche composant porte les opérations individuelles à l'intérieur de ce dialogue sous forme de composants Invoke, ReturnResult, ReturnError et Reject.
Qu'est-ce qu'un Invoke ID en TCAP ?
L'Invoke ID est un petit identifiant que l'initiateur attribue à chaque composant Invoke pour que le ReturnResult ou ReturnError correspondant puisse être rapproché de la requête. Il délimite les réponses au sein d'un même dialogue, à la manière d'un id de corrélation requête/réponse.
Qu'est-ce qu'un contexte applicatif TCAP ?
Le contexte applicatif est un identifiant d'objet dans la portion dialogue qui nomme l'application et la version utilisées par les deux pairs — par exemple un contexte MAP précis pour le routage SMS. Il indique au récepteur quelles opérations et formats de paramètres attendre dans le dialogue.
Quelle différence entre ReturnError et Reject ?
ReturnError signale un échec applicatif d'une opération qui a été comprise — par exemple le MAP absentSubscriber. Reject signale un problème protocolaire, tel qu'un code d'opération non reconnu ou un composant mal structuré, et est généré par le TCAP lui-même plutôt que par l'application.
Un même message TCAP peut-il porter plusieurs opérations ?
Oui. Un seul message de transaction peut porter plusieurs composants, si bien qu'un nœud peut regrouper plusieurs Invoke ou renvoyer plusieurs résultats dans un même Begin/Continue/End. Chacun se distingue par son Invoke ID, et les résultats peuvent être segmentés avec ReturnResult Not Last.
Spécifications sources
Les normes publiées sur lesquelles repose cette page. S'ouvre dans un nouvel onglet.