Transaction Capabilities Application Part

TCAP existuje ve dvou variantách:

• ITU TCAP popsaný v Q.771 až Q.775 se používá v sítích GSM/UMTS pro přenos MAP, CAP a INAP zpráv
• ANSI TCAP popsaný v T1.114 se používá v sítích CDMA2000 (v minulosti AMPS a TDMA, cdmaOne) pro přenos IS-41 zpráv

Obě varianty jsou definovány pomocí ASN.1, kódovány pomocí Basic Encoding Rules (BER) a slouží k podobným účelům, ale jsou vzájemně nekompatibilní. ANSI varianta je navržena s důrazem na jednoduchost a snadnou rozšiřitelnost pouhým přidáváním nových parametrů (tagů), případně definováním nových typů zpráv, ITU varianta používá poměrně komplikovaný mechanismus aplikačních kontextů. Obě varianty se v telekomunikačních sítích zřídkakdy setkávají, ale pokud k tomu dojde, je možné je rozlišit pomocí BER typů; zatímco ITU TCAP používá BER tagy aplikační, univerzální, případně kontextově závislé třídy (s hodnotami 0x00-0xBF), ANSI TCAP preferuje privátní tagy (s hodnotami 0xC0-0xFF), ve vnořených strukturách doplněné tagy kontextově závislé (s hodnotami 0x80-0xBF).

TCAP lze rozdělit na dvě podvrstvy:

• podvrstva komponent (Component Sublayer – CSL) – vyšší podvrstva, která využívá služeb TSL
• podvrstva transakcí (Transaction Sublayer – TSL)

TCAP umožňuje současné vedení několika dialogů neboli transakcí mezi stejnými subsystémy na stejných strojích (pro rozlišení strojů lze použít jejich point kódy nebo IP adresy, pro rozlišení subsystémů jejich Subsystem Number).

Dialog je identifikován jedním nebo dvěma Identifikátory transakce (Transaction ID, TID), z nichž jeden volí stroj, který zahajuje dialog, a druhý druhý účastník dialogu s vloženými dotazy. Operace (dotaz) v rámci dialogu je identifikován Identifikátorem vyvolání (InvokeId).

Dialogovou část (Dialogue Portion) zavedl TCAP ve verzi z roku 1993 (tzv. White Book). Dialogová část může být přítomna pouze v první a ve druhé zprávě dialogu a může obsahovat následující informace:

• Verzi protokolu TCAP (protocol version)
• Aplikační kontext (application context) – určuje protokol vyšší vrstvy (MAP, CAP nebo INAP) a jeho verzi
• Bezpečnostní kontext (security context) – udává, jak má být interpretována informace o utajení zprávy
• Důvěrnostní kontext (confidentiality context) – určuje použitý šifrovací algoritmus a jeho parametry

V praxi se dialogová část používá pouze u ITU TCAP, kde slouží k předání nebo dojednání aplikačního kontextu a tím i výběru aplikačního protokolu a jeho verze.

TCAP zprávy jsou formátovány podle pravidel Basic Encoding Rules (BER) – mají tvar vnořených trojic Type-Length-Value (typ, délka, hodnota). ITU používá pro Type název Tag, ANSI název Identifier. Jak Type tak Length mohou být jedno- i vícebytové; vícebytový typ začíná bytem 0x1F, 0x5F, 0x9F nebo 0xFF a končí bytem s hodnotou menší než 0x80; vícebytová délka začíná bytem s hodnotou větší než 0x80; tato hodnota zmenšená o 0x80 udává počet dalších bytů obsahujících údaj o délce. U složených struktur se objevuje nedefinovaná délka (0x80); struktura pak musí být zakončena dvojicí bytů s nulovou hodnotou, která představuje koncovou značku (EOC) – viz Basic Encoding Rules.

ITU TCAP zprávy mají následující strukturu (+ musí být přítomné, O může být přítomné, - nesmí být přítomné):

V ITU TCAP je Originating Transaction ID v jednom parametru s BER type 0x48, Destination Transaction ID v druhém parametru s BER type 0x49. Jejich přítomnost v TCAP zprávách je patrná z tabulky ITU TCAP zpráv.

ANSI TCAP zprávy:

ANSI TCAP zprávy obsahují vždy jeden parametr Transaction ID s BER typem 0xC7. V Unidirectional zprávách je tento parametr prázdný (má délku 0), ve zprávách Conversation With Permission a Conversation Without Permission obsahuje dva Transaction ID (má délku 8), v ostatních zprávách obsahuje jediný Transaction ID (má délku 4).

Dialogová část v ITU TCAP nese data protokolu (Application Protocol Data Unit – APDU), který řídí dialog nebo unidialog. Pro MAP a INAP slouží dialogové APDU k vytváření a ukončování (uvolňování) dialogů pro aplikační kontext zadaný v primitivech. Pro dialogové APDU jsou definována následující primitiva:

Komponentová část obsahuje jednu z komponent:

ITU komponenta obsahuje Invoke ID s typem 0x02 a délkou 1, kód operace s typem 0x02 a sadu parametrů s typem 0x30.

ANSI komponenta obsahuje Invoke ID s typem 0xCF a délkou 1, kód operace s typem 0xD1 a sadu parametrů s typem 0xF2.

Následuje hexadecimální výpis TCAP zprávy, která obsahuje SMS odeslanou mobilním telefonem (MO-SMS) a transformovanou MSC na MAP zprávu:

 62 74 48 04 00 02 00 30 6B 1A 28 18 06 07 00 11
 86 05 01 01 01 A0 0D 60 0B A1 09 06 07 04 00 00
 01 00 19 02 6C 50 A1 4E 02 01 01 02 01 2E 30 46
 80 05 70 31 42 44 44 84 06 A1 70 91 92 55 55 04
 35 2F 09 00 70 97 92 62 23 04 00 90 20 11 80 01
 24 00 27 43 50 7A 0E A2 A3 CB 20 71 79 4E 07 B1
 C3 EE 73 3D 7C 2E 83 D2 20 74 D8 5E 06 95 ED 65
 39 68 5E 2E BB 01 00

Podle hodnot Tag-Length-Value lze zprávu dekódovat takto:

 '--> 62|74  ''<- Begin''
        |
        '--> 48|04:00 02 00 30    ''<- Transaction ID''
        |
        '--> 6B|1A   ''<- Začátek dialogové části'' 
               |
               '--> 28|18   ''<- External Constructor''
                      |
                      '--> 06|07:00 11 86 05 01 01 01   ''<- id-as-dialogue''
                      |
                      '--> A0|0D
                             |
                             '--> 60|0B   ''<- AARQ APDU''
                                    |
                                    '--> A1|09   ''<- Aplikační kontext''
                                           |
                                           '--> 06|07:04 00 00 01 00 19 02   ''<- hodnota aplikačního kontextu''
        |
        '--> 6C|50     ''<- Začátek komponentové části''
               |
               '--> A1|4E     ''<- Invoke Component (Last)''
                      |
                      '--> 02|01:01    ''<- Component Id (invoke id)''
                      |
                      '--> 02|01:2E    ''<- Kód operace''
                      |
                      '--> 30|46       ''<- Začátek parametrů''
                             |
                             '--> 80|05:70 31 42 44 44        ''<- SM-RP-DA(BCD)''
                             |
                             '--> 84|06:A1 70 91 92 55 55     ''<- SM-RP-OA(BCD)''
                             |
                             '--> 04|35:2F 09 00 70 97 92 62 23 04 00 90 20 11 80 01 24 00 27 43 50 7A 0E A2 A3 CB 20 71 79 4E 07 B1 C3 EE 73 3D 7C 2E 83 D2 20 74 D8 5E 06 95 ED 65 39 68 5E 2E BB 01   ''<- SM-RP-UI''

Následuje hexadecimální výpis ANSI TCAP zprávy, která obsahuje SMS odeslanou mobilním telefonem (MO-SMS) a transformovanou MSC na IS-41 zprávu:

 E2 81 9F C7 04 90 00 FF 06 E8 81 96 E9 81 93 CF
 01 00 D1 02 09 35 F2 81 89 9F 74 02 10 02 9F 69
 62 00 03 20 05 70 01 4F 12 C5 ...
 88 05 19 95 22 29 78 9F 70 09 02 00 21 0A 19 25
 80 27 64 9F 6E 09 02 00 21 0A 19 75 13 54 15

Tuto ANSI zprávu lze dekódovat takto:

 '--> E2|81 9F  ''<- Query With Permission''
        |
        '--> C7|04:90 00 FF 06    ''<- Transaction ID''
        |
        '--> E8|81 96     ''<- Posloupnost komponent''
               |
               '--> E9|81 93     ''<- Invoke Component (Last)''
                      |
                      '--> CF|01:00    ''<- Component Id (invoke id)''
                      |
                      '--> D1|02:09 35    ''<- Kód operace''
                      |
                      '--> F2|81 89       ''<- Parameter set''
                             |
                             '--> 9F 74|02:10 02        ''<- SMS-Teleservice Identifier''
                             |
                             '--> 9F 69|62:00 03 20 05 70 01 4F 12 C5 ...    ''<- SMS-Bearer Data''
                             |
                             '--> 88|05:19 95 22 29 78    ''<- Mobile Identification Number''
                             |
                             '--> 9F 70|09:02 00 21 0A 19 25 80 27 64  ''<- SMS-OriginalOriginatingAddress''
                             |
                             '--> 9F 6E|09:02 00 21 0A 19 75 13 54 15  ''<- SMS-OriginalDestinationAddress''

Signalizační sítě byly díky svému oddělení od datových sítí považovány za bezpečné. S přechodem na SIGTRAN se zvyšuje nebezpečí průniku do těchto sítí. Protokol TCAP je zranitelný díky možnosti podvrhnout adresu odesilatele v datech, která přepravuje, čehož se zneužívá při SMS spoofingu. Této formě zranitelnosti lze předcházet použitím TCAP segmentace.

• 1988 Blue Book – první verze
• 1993 White Book – zavedlo dialogovou část
• 1997 – pouze menší změny

Standard z roku 1988 dělil Transaction Capabilities (TC) na dvě části:

• Intermediate Services Part (ISP) – měly pokrývat vrstvy transportní, relační a prezentační; ve standardu však nebyly blíže definovány
• Transaction Capabilities Application Part (TCAP) – aplikační vrstva TC

V pozdějších standardech už ISP chybí, čímž se TC stává synonymem pro TCAP.