Información: Señalización Parte de Aplicación de Capacidad de Transación (TCAP)

Información
Señalización
Parte de aplicación de capacidad de

transación (TCAP)
A30808-X3245-X516-1-7818
Parte de aplicación de capacidad de transación Información
(TCAP) Señalización
!
Nota importante respecto a la seguridad de productos
Determinadas piezas de sistemas eléctricos llevan aplicada siempre tensión. Algunas partes pueden
presentar también altas temperaturas de trabajo.
La no observación de estas condiciones y de las advertencias puede originar daños personales y ma-
teriales.
Por ello, partimos del supuesto de que los sistemas serán instalados y mantenidos únicamente por
personal cualificado y capacitado.
El sistema cumple con las exigencias estándar EN 60950. Todos los equipos conectados han de
cumplir con las medidas de seguridad aplicadas.
Copyright (C) Siemens AG 1998
Editado por el Grupo Redes de Comunicación Públicas

Hofmannstraße 51
D-81359 München
Reservada la posibilidad de modificaciones técnicas.

Las características y facilidades sólo tienen validez si se han
estipulado explícitamente mediante contrato escrito.
2 A30808-X3245-X516-1-7818
Información Parte de aplicación de capacidad de transación
Señalización (TCAP)
Este documento abarca un total de 36 páginas. Todas las páginas corresponden al es-
tado 1.
Indice
1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Estructura de CCS7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 Parte transferencia de mensaje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Parte control de conexión de señalización . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Parte aplicación de capacidades de transacción . . . . . . . . . . . . . . . . . . . . . 9
2.4 Usuarios TCAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Estructura de la Parte aplicación de capacidades

de transacción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1 Primitivas de manejo de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Primitivas de manejo de diálogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Mensajes TCAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 Flujo de información de un diálogo estructurado . . . . . . . . . . . . . . . . . . . . 16
4 Implementación de TCAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5 Formatos de mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1 Unidad de señalización de mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2 Mensaje SCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3 Mensaje TCAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.3.1 Parte transacción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3.2 Parte diálogo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3.3 Parte componente de mensaje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6 Funciones TCAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1 Manejo de componentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2 Manejo de transacción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.3 Manejo de control de diálogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.4 Funciones comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7 Abreviaturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8 Palabras clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A30808-X3245-X516-1-7818 3
Figuras
Fig. 1.1 Empleo de los servicios TCAP para televoto y actualizaciones de
situación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Fig. 2.1 TCAP insertada en la parte pila protocolo de CCS7. . . . . . . . . . . . . . . . . 7
Fig. 3.1 Estructura de TCAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Fig. 3.2 Flujo de información para un diálogo estructurado (clase 1 ó 3) . . . . . . 16
Fig. 4.1 Implementación de la TCAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Fig. 5.1 Inserción del mensaje TCAP en la unidad de señalización de
mensajes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Fig. 6.1 Máquina de estado de componentes para clases de operación 1, 2 y 3 27
Fig. 6.2 Máquina de estado de transacción para diálogo estructurado . . . . . . . . 31
4 A30808-X3245-X516-1-7818
Información Señalización Parte de aplicación de capacidad de transación
(TCAP)
1 Introducción
(Inscripción)
SSP
(Inscripción)
TCAP SSP
TCAP
SCP
Votante A
Votante B
a. Televoto
HLR
BTS/BSC
TCAP/MAP
MSC/VLR
Abonado
móvil
b. Actualización de situación
Fig. 1.1 Empleo de los servicios TCAP para televoto y actualizaciones de

situación
La Parte aplicación de capacidades de transacción (TCAP) es un protocolo de señali-

zación del Sistema de señalización por canal común No. 7 (CCS7) normalizado por la
ITU y el CCITT (Libro blanco Q.771-Q.774 y ETS 300.287), basado en los protocolos
de capa 7 del OSI, Elemento de servicio control de asociación (ACSE) y Elemento de
servicio de operaciones a distancia (ROSE). Este último ofrece servicios para la invo-
cación de operaciones a distancia así como para la posterior recepción de respuestas
a esas operaciones. Las operaciones a distancia son acciones o tareas ejecutadas por
un elemento de red a distancia, pero iniciadas o solicitadas por el elemento de red de
servicio.
La TCAP provee un mecanismo para la ejecución de operaciones a distancia en un en-
torno de red CCS7 que se puede emplear para apoyar diversos servicios. De esta ma-
nera, la TCAP evita la ineficacia de desarrollar procedimientos específicos que realicen
servicios similares para cada aplicación
La TCAP también lleva a cabo el control de asociación de aplicación entre procesos de
aplicación o entidades iguales en diferentes elementos de red. Una transacción es una
A30808-X3245-X516-1-7818 5
Parte de aplicación de capacidad de transación Información Señalización
(TCAP)
conexión no relacionada con circuito (virtual), empleada para intercambiar información

mediante mensajes TCAP.
La figura Fig. 1.1ilustra los servicios TCAP para televoto. En vez de proveerse acceso
al centro de inscripción (un SCP) para cada abonado, distintos SSP son responsables
de inscribir la selección del abonado. Posteriormente son invocados servicios TCAP
para actualizar los contadores de inscripción (es decir, una operación a distancia) alma-
cenados en el SCP centralizado. Debido a que el tiempo de inscripción total se distribu-
ye por todos los SSP participantes, este mecanismo permite al SCP manejar un número
mucho mayor de transacciones con resultados de votación.
Dentro de la red del servicio móvil terrestre público, por ejemplo (Fig. 1.1.), la Parte
aplicación móvil (MAP) emplea servicios TCAP para actualizar la información de situa-
ción de abonado móvil en el HLR (es decir, una operación a distancia). Después que
la estación móvil termina de pasar su información de situación más reciente al MSC,
éste actualiza su Registro de posiciones de visitantes (VLR) y envía al HLR un mensaje
TCAP/MAP contentivo de dicha información.
6 A30808-X3245-X516-1-7818
(TCAP)
2 Estructura de CCS7
Elemento de red Elemento de red distante
OSI
Usuario TCAP
Primitivas de Primitivas de
tratamiento tratamiento de
de componente diálogo
7 TCAP
Mensajes TCAP
N_Unitdata ind
N_Notice ind
6
5 ISP
4 Mensajes SCCP
(UDT/UDTS)
N_Unidata req
NSP
SCCP
3 (conexión)
MTP_Transfer ind
MTP_Transfer req
2
MTP
1
Unidades de
señalización
Fig. 2.1 TCAP insertada en la parte pila protocolo de CCS7
Los distintos elementos de red se conectan a una red de señalización que se emplea
para apoyar la comunicación entre esos elementos. El sistema de señalización por ca-
nal común No. 7 (CCS7) normalizado por la ITU/CCITT es un sistema de señalización
estructurado por niveles implementado en esta red dedicada.
El CCS7 posee las ventajas siguientes:
– separación total de los datos de señalización y de información (p.ej., voz, datos)
– concentración de la información de señalización en unos pocos enlaces de señali-
zación
– el sistema de señalización tiene operación y mantenimiento independientes
– más confortable intercambio de información por medio de unidades de señalización
– supervisión de la secuencia de flujo de información, control de duplicación de pér-
dida de unidades de señalización.
Cada nivel de CCS7 define un conjunto de reglas y procedimiento que lleva a cabo ta-
reas específicas cuando se está efectuando el intercambio de la información de seña-
A30808-X3245-X516-1-7818 7
(TCAP)
lización. Este conjunto de reglas y procedimientos se denomina protocolo de

señalización (Fig. 2.1).
La Parte transferencia de mensaje (MTP) y la Parte control de la conexión de señaliza-
ción (SCCP) son protocolos de señalización comunes que ofrecen sus servicios a toda
aplicación CCS7. Combinadas constituyen la Parte servicio de red (NSP), comparable
a las capas OSI 1 a 3 (capas física, capa de enlace de datos, y capa de red).
La Parte servicio intermedio (ISP) es comparable con las capas OSI 4 a 6, es decir, las
capas de transporte, sesión y presentación. Sin embargo, se carece de una especifica-
ción mayor de ITU/CCITT para la ISP (en blanco).
The Parte aplicación de capacidades de transacción (TCAP) es un protocolo de seña-
lización de aplicación (OSI capa 7, capa de aplicación). La TCAP se comunica directa-
mente con SCCP toda vez que ISP está en blanco para CCS7. Los usuarios TCAP son
aplicaciones (p.ej., MAP) que usan servicios TCAP.
2.1 Parte transferencia de mensaje

La Parte transferencia de mensaje (MTP) es un medio de transporte independiente del
usuario que garantiza a los niveles superiores efectuar una transmisión de datos libre
de errores dentro de una red de señalización. Dentro de la MTP se definen tres proto-
colos separados que tienen las funciones siguientes.
• El nivel físico (nivel 1) lleva a cabo las funciones de enlace de datos de señalización.
Estas últimas definen las características físicas, eléctricas y funcionales de un en-
lace de datos de señalización y los medios para su acceso.
• El nivel de enlace de datos (nivel 2) efectúa las funciones de enlace de señalización.
Estas definen los procedimientos para una transferencia confiable de los mensajes
de señalización a través de un enlace de datos de señalización.
• El nivel de red (nivel 3) realiza las funciones de red de señalización. Estas definen
los procedimientos y funciones de transporte que son comunes a o independientes
de la operación del enlace de señalización.
La MTP transmite mensajes de señalización a su destino mediante unidades de seña-
lización. Estas son estructuras fijas de datos en las que el usuario MTP puede insertar
su información de señalización. Según la información contenida en la unidad de seña-
lización, la MTP distingue las siguientes clases de unidades de señalización:
– La unidad de señalización de mensajes contiene información de señalización de un
usuario MTP distante o local. Este (p.ej., SCCP local) se comunica con la MTP (es
decir, transmitiendo y recibiendo información de señalización) por medio de la peti-
ción de transferencia MTP y de primitivas de indicación. La longitud de la unidad de
señalización de mensaje se adapta al contenido de la información de señalización.
– La unidad de señalización de estado de enlace contiene información de estado de
enlace de señalización. Esta es determinada por la MTP y transmitida a las entida-
des MTP adyacentes (puntos de señalización) por medio de esas unidades de se-
ñalización. La unidad de señalización de estado de enlace tiene una longitud fija.
– La unidad de señalización de relleno no contiene ninguna información. Los puntos
de señalización intercambian estas unidades para una sincronización continua.
El destino del mensaje de señalización está caracterizado por un código de punto (des-
tino) que es un identificador unívoco del punto de señalización dentro de una red de se-
ñalización. Los mensajes de señalización, cuyo destino se halla afuera de esta una red
de señalización, requieren las capacidades de encaminamiento de la SCCP.
8 A30808-X3245-X516-1-7818
(TCAP)
2.2 Parte control de conexión de señalización

La Parte control de conexión de señalización (SCCP) apoya una transferencia de datos
sin conexión y orientada a conexión así como extiende las funciones de encaminamien-
to de la MTP (para destinos fuera de la red de señalización).
La transferencia de datos sin conexión es un modo de transferencia que no requiere del
establecimiento de una conexión lógica. Este es el modo de transferencia empleado por
la TCAP. La transferencia de datos orientada a conexión es un modo de transferencia
que exige una conexión lógica. Los procedimientos apropiados de SCCP establecen
esa conexión lógica y proporcionan los recursos de memoria necesarios antes de que
pueda llevarse a cabo la transferencia de datos. Al final de la transferencia de datos, la
SCCP inicia las acciones necesarias para liberar la conexión y los recursos de memoria
asociados.
Las funciones de encaminamiento SCCP adicionales permiten al usuario SCCP em-
plear un código de punto de destino y un número de subsistema, o un título global. Este
último puede direccionar un nodo de red (p.ej., bases de datos y centros de computa-
ción) o a otro usuario SCCP adentro o afuera de la red de señalización originante.
Dado que para la TCAP sólo se necesitan los servicios SCCP sin conexión, se emplean
los siguientes mensajes SCCP para transportar información de usuario.
– Normalmente se emplea (X)Unitdata ((XUDT) para el transporte de la información
de señalización de acuerdo con las especificaciones de la transferencia de datos
sin conexión.
– El mensaje (X)Unitdata Service ((XUDTS) se emplea para devolver la información
de señalización recibida con un mensaje UDT al punto de señalización originante
cuando la UDT no puede alcanzar su destino. El usuario SCCP tiene que pedir este
atributo de servicio (opción de devolución).
2.3 Parte aplicación de capacidades de transacción

La Parte aplicación de capacidades de transacción (TCAP) es un elemento de servicio
de aplicación que provee un conjunto de herramientas y servicios en un entorno sin co-
nexión, que puede emplearse para una aplicación distribuida en un nodo para la invo-
cación o ejecución de operaciones a distancia en otro nodo.
Los usuarios TCAP intercambian componentes de mensajes simples, es decir, elemen-
tos de información de señalización, con la TCAP empleando las primitivas de tratamien-
to de componentes. Los componentes de mensajes asociados o relacionados se
identifican por medio de identificadores de diálogo idénticos.
La aplicación hace uso de las primitivas de tratamiento de diálogo para pedirle a la
TCAP que establezca un diálogo estructurado entre las aplicaciones, y envía los com-
ponentes recibidos con el mismo identificador de diálogo al destino deseado dentro de
un mensaje TCAP. La parte TCAP permite un intercambio de información asincrónica
dúplex total tras el establecimiento de una asociación.
Un diálogo estructurado significa que la TCAP es capaz de correlacionar directamente
el componente de mensaje transmitido a una respuesta posiblemente recibida. Para un
diálogo no estructurado no es posible ninguna correlación entre un componente de
mensaje transmitido y cualquier respuesta recibida (ninguna conexión virtual, lógica).
De acuerdo con esas opciones de transferencia, la parte TCAP distingue cuatro clases
de operación.
– Clase 1
A30808-X3245-X516-1-7818 9
(TCAP)
– Esta clase se emplea dentro de un diálogo estructurado donde la aplicación espera

un informe de operación indicativo del resultado fructífero o infructuoso.
– Clase 2
que el informe de operación sólo arroje que el resultado sea de infructuoso (el re-
sultado supuesto es de fructífero).
– Clase 3
que el informe de operación sólo arroje que el resultado sea de fructífero (el resul-
tado supuesto es de infructuoso).
– Clase 4
– Esta clase se emplea dentro de un diálogo estructurado o no estructurado donde la
aplicación no espere ningún informe de operación.
– La Parte aplicación móvil (MAP), empleada para aplicaciones móviles específicas,
p.ej., actualización de ubicación, interrogación, servicios de mensajes cortos, trans-
ferencia
2.4 Usuarios TCAP

Los usuarios de capacidades de transacción son aplicaciones que emplean servicios
TCAP. Los siguientes son ejemplos de servicios prestados por tales aplicaciones:
– Servicios suplementarios ISDN
– La interrogación de estados operativos o la iniciación de acciones en nodos de red
distantes para operación y mantenimiento, es decir, Parte operación y manteni-
miento (OMAP)
– La Parte aplicación móvil (MAP) que se emplea para aplicaciones móviles especí-
ficas, p.ej., actualización de ubicación, interrogación, servicios de mensajes cortos,
transferencia
– Parte aplicación IN.
10 A30808-X3245-X516-1-7818
(TCAP)
3 Estructura de la Parte aplicación de capaci-

dades
de transacción
Usuarios TC
Primitivas de Primitivas de
TC_RESULTNL req/ind
TC_U_REJECT req/ind
TC_U_ERROR req/ind
TC_U_ERROR req/ind
TC_U_ABORT req/ind
tratamiento de tratamiento de
TC_RESULT req/ind
TC_INVOKE req/ind
TC_U_CANCEL req
TC_R_REJECT ind
TC_L_CANCEL ind
componente diálogo
TC_L_REJECT ind
TC_BEGIN req/ind
TC_CONT req/ind
TC_P_ABORTind
TC_END req/ind
TC_NOTICE ind
TC_UNI req/ind
UNI
Diálogo
BEGIN
Manejador de transacción
Manejador de componente CONTI-
de diálogo
END
ABOR
Transacción
N_UNITDATA req/ind
N_NOTICE ind
SCCP
Fig. 3.1 Estructura de TCAP
La definición de la TCAP según la Recomendación Q.771-Q.774 de la ITU/CCITT men-

ciona dos subcapas, o sea, la de diálogo y la de transacción (Fig. 3.1.
La subcapa de diálogo se compone de un manejador de componente y de un maneja-
dor de diálogo. El manejador de componente es, en efecto, la realización de la
ITU/CCITT del elemento de servicio de aplicación OSI, ROSE. Sin embargo, se da una
diferencia mayor en el hecho de que la TCAP apoya la segmentación/reensamblaje a
nivel de usuario, es decir, manejar parámetros de gran resultado mediante su división
A30808-X3245-X516-1-7818 11
(TCAP)
en varios resultados menores. El manejador de diálogo maneja todos las primitivas de

interfaz de usuario para elaborar diálogos estructurados y no estructurados.
La subcapa de transacción consta del manejador de transacción, que mapea los diálo-
gos a las transacciones. El mismo requiere la realización de las tareas siguientes:
– gestión de la información de dirección de transacción
– mapeo de los parámetros de diálogo a parámetros de transacción
– manejo de las primitivas de la red en comunicación con la SCCP
– codificación/decodificación de mensajes.
La codificación/decodificación de mensajes es una función de capa de presentación
(capa 6) que convierte la información representada por una sintaxis local en su sintaxis
de transferencia (como se transmite realmente en el enlace) y viceversa, con arreglo a
las reglas básicas de la decodificación.
La parte TCAP intercambia información con sus usuarios (aplicaciones) por medio de
primitivas. Existen dos clases de primitivas:
– las que manejan componentes, que transmiten elementos de información entre la
TCAP y sus usuarios
– las que manejan diálogos, que transmiten información de diálogo (p.ej., diálogo es-
tructurado no estructurado, pedido o abierto) ya sea de la aplicación a la TCAP, o
de la TCAP a la aplicación.
Tanto la información de componente como la de diálogo permiten a la TCAP formar los
mensajes que se transmiten a la TCAP distante a través de los servicios sin conexión
de la SCCP. Por lo tanto, el mensaje TCAP se trata como información de usuario SCCP,
se pone en una primitiva de servicio de red (N_UNITDATA req), y se transmite a la SC-
CP. Del lado de recepción, la entrega del mensaje TCAP se efectúa por la primitiva de
indicación.
La primitiva de indicación N_NOTICE del servicio de red devuelve un mensaje TCAP
previamente enviado y que no pudo alcanzar su destino debido a irregularidades de la
señalización (p.ej., subsistema direccionado no disponible).
3.1 Primitivas de manejo de componentes

Los usuarios TC intercambian información (insertada en los componentes TCAP) por
medio de las primitivas de manejo de componentes. Más abajo se presenta un resumen
de las primitivas de manejo de componentes. Las primitivas de petición contienen com-
ponentes transmitidos a la TCAP, y se devuelven al usuario TC los componentes de las
primitivas de indicación.
TC_INVOKE req/ind
Se solicita a la TCAP la invocación de una operación a distancia con la primitiva de pe-
tición. Del lado distante se inicia la operación con la primitiva de indicación. Cada invo-
cación de operación es identificada por un identificador de identificación, permitiendo la
activación simultánea de varias invocaciones de las mismas operaciones u operaciones
diferentes dentro del mismo diálogo. También es posible unir una invocación a otra in-
vocación de operación activada previamente.
TC_RESULTL req/ind
Esta primitiva se emplea para la transmisión del componente (es decir, del elemento de
información) que contiene una indicación de operación culminada fructíferamente. Esta
12 A30808-X3245-X516-1-7818
(TCAP)
primitiva se emplea para las clases de operación 1 y 3, para las cuales se espera un
resultado positivo.
TC_RESULTNL req/ind
El componente incluido en esta primitiva contiene la parte no final de un resultado seg-
mentado.
TC_U_ERROR req/ind
Esta primitiva transporta un componente que contiene un error, generado por el usua-
rio, que indica el resultado infructuoso de una operación. Esta primitiva implica que la
aplicación distante acepta y comprende la operación anteriormente invocada, pero que
la operación no es objeto del tratamiento correcto. Esta primitiva se emplea sólo para
las clases de operación 1 y 2 en que se informe un resultado negativo.
TC_R_REJECT ind
El componente incluido en este primitiva indica a la aplicación local que errores en el
encabezamiento del componente han causado que la TCAP no haya podido aceptar
una operación previamente invocada.
TC_L_REJECT ind
Debido a errores, un componente recibido puede ser rechazado por la TCAP, la cual a
su vez informa a la aplicación por medio de esta primitiva.
TC_L_CANCEL ind
Esta primitiva indica que el temporizador de supervisión de operación local, vigilando
una invocación activa, ha expirado. Al mismo tiempo, la invocación activa se pone en
reposo.
TC_U_CANCEL req
También es posible la cancelación por la aplicación local de operaciones invocadas pre-
viamente. Si la petición de cancelación se recibe antes de transferirse la operación al
extremo distante, la operación es cancelada. Por otro lado, una vez transmitida ya la
operación a la aplicación distante, se instruye a la TCAPA rechazar cualquier respuesta
recibida del extremo distante, ignorante de la cancelación.
3.2 Primitivas de manejo de diálogo

Las primitivas de manejo de diálogo instruyen a la TCAP la creación de asociaciones o
transacciones entre dos aplicaciones iguales de acuerdo con el concepto de diálogo es-
tructurado o no estructurado. Las primitivas de petición pasan los parámetros de diálo-
go a la TCAP. Las primitivas de indicación transmiten información de diálogo a la
aplicación, e incluyen opcionalmente información de usuario (componentes).
TC_UNI req/ind
Esta primitiva (unidireccional) porta información para crear un diálogo no estructurado
y transmitir los componentes que fueran previamente entregados o incluidos. La aplica-
ción es informada en el extremo distante mediante esta primitiva.
A30808-X3245-X516-1-7818 13
(TCAP)
TC_BEGIN req/ind
Con esta primitiva una aplicación solicita un nuevo establecimiento de diálogo estructu-
rado. La identificación local del diálogo se efectúa por un identificador de diálogo nuevo.
Esta primitiva también instruye a la TCAP transmitir todos los componentes entregados
previamente (dentro de las primitivas de manejo de componentes).
Del lado de recepción la primitiva de indicación informa a la aplicación de un nuevo diá-
logo. La primitiva de indicación, además, puede indicar que el mensaje TCAP ya con-
tiene componentes.
TC_CONT req/ind
Esta primitiva solicita de la TCAP que transmita componentes nuevos dentro del mismo
diálogo. La aplicación distante recibe esos componentes con la primitiva de indicación.
TC_END req/ind
La aplicación emplea esta primitiva para solicitar de la TCAP que finalice el diálogo de
manera normal. Según el procedimiento que se emplee para finalizar el diálogo, la apli-
cación pudiera ser o no ser informada en el extremo distante.
• Fin básico
La aplicación emplea esta primitiva para solicitar de la TCAP que finalice el diálogo
de manera normal. Según el procedimiento que se emplee para finalizar el diálogo,
la aplicación pudiera ser o no ser informada en el extremo distante.
• Fin organizado de antemano
La TCAP es instruida por ambas aplicaciones que finalice el diálogo y descarte to-
das las operaciones pendientes, lo cual implica que la TCAP dejará de transmitir
todo componente de mensaje en lo sucesivo.
TC_U_ABORT req/ind
Las aplicaciones pueden emplear la primitiva de cancelación anormal para la finaliza-
ción inmediata de diálogos estructurados. Como resultado, la TCAP descarta todos los
componentes pendientes y transmite la información de cancelación anormal al otro la-
do, el cual informa a la respectiva aplicación.
TC_P_ABORT ind
El manejador de transacción de TCAP también puede efectuar cancelaciones anorma-
les de diálogos tras la detección de situaciones anormales. En este caso la TCAP infor-
ma a la aplicación mediante la primitiva de indicación de cancelación anormal
(cancelación anormal del proveedor).
TC_NOTICE ind
La primitiva de indicación informa a la aplicación sobre la entrega infructuosa de un
mensaje anteriormente enviado.
3.3 Mensajes TCAP

Los mensajes TCAP son portadores de información estructurada que se intercambian
entre iguales de TCAP. Según la información que un mensaje tal porte y su función
(p.ej., abrir un diálogo), se distinguen los mensajes siguientes.
14 A30808-X3245-X516-1-7818
(TCAP)
UNIDIRECTIONAL (UNIDIRECCIONAL)
Los mensajes TCAP unidireccionales llevan información (componentes) al extremo dis-
tante dentro de un diálogo no estructurado. No se espera respuesta.
BEGIN (COMIENZO)
El mensaje de comienzo abre una transacción nueva con el extremo distante. De soli-
citarlo la aplicación, este mensaje pudiera ya contener componentes de mensaje.
CONTINUE (CONTINUAR)
Este mensaje intercambia componentes entre iguales de la TCAP dentro de una tran-
sacción existente.
END (FIN)
Una entidad emplea un mensaje de fin para informar al otro lado que la transacción ha
sido cerrada. De ser necesario, el mensaje puede contener los últimos componentes
pendientes.
ABORT (CANCELACION ANORMAL)

Este mensaje se emplea para informar a la otra entidad sobre la cancelación anormal
de una transacción por el manejador de transacciones tras detectarse una irregularidad,
o por la aplicación.
A30808-X3245-X516-1-7818 15
(TCAP)
3.4 Flujo de información de un diálogo estructurado
Elemento de red Distante
Local Appli- TCAP TCAP Remote

cation TC_INVOKE (1) req
TC_INVOKE (2) req
TC_BEGIN req
BEGIN(INVOKE(1),INVOKE(2))
TC_BEGIN ind
TC_INVOKE(1) ind
TC_INVOKE(2) ind
TC_RESULT(1) req
TC_RESULT(2) req
TC_CONT req
CONTINUE(RESULT(1),RESUT(2))
TC_CONT ind
TC_RESULT(1) ind
TC_RESULT(2) ind
Basic End
TC_END req
END (vacío)
TC_END ind
Pre-
arranged
TC_END req
User Abort
TC_U_ABORT ind TC_END req
ABORT
TCAP Abort
TC_U_ABORT ind
Detectado error
TC_P_ABORT ind ABORT

TC_P_ABORT ind
Fig. 3.2 Flujo de información para un diálogo estructurado (clase 1 ó 3)
16 A30808-X3245-X516-1-7818
(TCAP)
La invocación de operaciones distantes dentro de un diálogo estructurado se puede en-

tender de acuerdo con el diagrama siguiente (Fig. 3.2).
Una aplicación (local) implementada en cierto elemento de red (p.ej., la parte aplicación
móvil en el registro de posiciones de visitantes) inicia dos operaciones a ser llevadas a
cabo por la aplicación distante (p.ej., actualizar los datos de posición de dos abonados
móviles en el registro de posiciones propio).
La aplicación transmite su información a la TCAP mediante primitivas de invocación,
cada una de las cuales lleva la información para una operación distante. A ésta última
se le asigna un identificador de operación (ID de invocación) permitiéndole así a la
TCAP correlacionar todas las respuestas posibles a una operación iniciada previamen-
te.
La aplicación transmite posteriormente su información de diálogo a la TCAP mediante
la primitiva de petición de comienzo. Esta última instruye a la TCAP que abra un diálogo
estructurado y, al mismo, tiempo, que transmita los componentes anteriormente entre-
gados de INVOKE(1) e INVOKE(2).
La TCAP crea un mensaje de comienzo formado por una parte transacción que da in-
formación sobre el diálogo, y por una parte componente que contiene los elementos de
información de la aplicación. Mediante los servicios sin conexión de la SCCP, el men-
saje se transporta a la TCAP distante, la cual evalúa la información y la transfiere a la
aplicación remota en dos pasos:
– La primitiva de indicación de comienzo informa a la aplicación sobre el nuevo diálo-
go.
– Más tarde se transmite cada componente separadamente a la aplicación distante
mediante primitivas de indicación.
La aplicación remota concluye las operaciones fructíferamente y devuelve los resulta-
dos a la TCAP (clase 1 ó 3). Más tarde, mediante la primitiva de petición de continuar,
la aplicación pide a la TCAP que transmita los resultados dentro del mismo diálogo. La
TCAP forma un mensaje continuo contentivo de ambos resultados y lo envía a la enti-
dad TCAP local.
La primitiva de indicación de continuación informa a la aplicación local acerca de los
componentes entrantes enviados dentro de un diálogo abierto previamente. Más tarde,
esos resultados se entregan a la aplicación local por medio de primitivas de indicación
de resultado.
Es posible la invocación de otras operaciones más dentro de este diálogo. Al final el diá-
logo estructurado es concluido de acuerdo con los principios de un fin básico u organi-
zado de antemano. No obstante, se puede efectuar la cancelación anormal del diálogo
debido a una eventual detección de irregularidades.
• Fin básico
El fin básico es iniciado por una aplicación (p.ej., la aplicación local) mediante la pri-
mitiva de petición de fin. Esta instruye a la TCAP la creación de un mensaje de fin
y la inclusión de todo componente que pueda estar pendiente. El mensaje es trans-
mitido a la TCAP y ésta informa a la aplicación distante mediante primitiva de indi-
cación de fin.
A30808-X3245-X516-1-7818 17
(TCAP)
• Fin organizado de antemano

El procesamiento de fines organizados de antemano es local. La aplicación local
instruye a la TCAP que descarte todos los componentes pendientes y que libere to-
dos los recursos relacionados con diálogo (p.ej., identificador de transacción).
En el fin distante, la TCAP cierra el diálogo ya sea a petición de la aplicación (primi-
tiva de petición de fin), o al expirar un temporizador de supervisión de diálogo.
• Cancelación anormal de usuario
La terminación es solicitada por la aplicación (p.ej., aplicación local) mediante una
primitiva de cancelación anormal de usuario. Esta hace que la TCAP envíe un men-
saje de cancelación anormal a la TCAP distante, donde la aplicación distante es in-
formada mediante una primitiva de indicación de cancelación anormal.
• Cancelación anormal de TCAP
La TCAP puede efectuar la cancelación anormal de un diálogo tras la detección de
irregularidades (p.ej., en la TCAP distante durante la decodificación de mensajes).
En este caso, la TCAP se encarga de informar a la aplicación local mediante una
primitiva de indicación de cancelación anormal, y a la TCAP distante mediante men-
saje de cancelación anormal.
18 A30808-X3245-X516-1-7818
(TCAP)
4 Implementación de TCAP
LTG GP
Funciones de procesamiento de llamadas CP
Usuarios TC
Parte aplicación capacidades de transacción
Parte control de conexión de señalización
CCNC
Parte transferencia de mensajes
CP
BAP CAP
Funciones de procesamiento de llamadas CP
Usuarios TC
Administración Funciones Parte aplicación de capacidades de transacción

de mantenimiento
Parte control de conexión de señalización
IOC IOC
IOP IOP
IOP con IOP:SCDV/X con
interfaces X.25 interfaces Memoria común: recursos TCAP
OMS LMT
Fig. 4.1 Implementación de la TCAP
A30808-X3245-X516-1-7818 19
(TCAP)
La implementación de la Parte aplicación de capacidades de transacción se efectúa a

modo de una función de software en el Procesador de coordinación (CP) y en el Proce-
sador de grupo (GP) en el Grupo de conexión (LTG) (Fig. 4.1).
El software del CP contiene una Parte procesamiento de llamadas y una Parte proce-
samiento de no llamadas. El software de procesamiento de llamadas se encuentra car-
gado tanto en el Procesador básico (BAP) y Procesador de llamadas (CAP). Sin
embargo, el BAP ejecuta las tareas de procesamiento de llamadas cuando hay dispo-
nibilidad de tiempo real de procesamiento. La parte de procesamiento de no llamadas
se encuentra cargada en el BAP.
La Parte procesamiento de no llamada se divide en una parte de administración y una
de mantenimiento. La administración CP participa principalmente en el mantenimiento
de la base de datos a través de comandos MML. Estos comandos pueden introducirse
en un Terminal de operación y mantenimiento local (LMT) conectado al CP a través de
un procesador de entrada/salida para dispositivos de comunicación de datos en serie
(IOP:SCDV/X). No obstante, las funciones de administración también son factibles en
un Centro de operación y mantenimiento (OMC) centralizado que es parte del Sistema
de operación y mantenimiento (OMS). El OMC se conecta al CP a través de un proce-
sador de entrada/salida con una interfaz X.25 (IOP:SCDP).
La TCAP se suma a la parte procesamiento de llamadas en el CP y el GP que maneja
todas las tareas de llamadas, como son, por ejemplo, el establecimiento y la liberación
de llamadas.
El Control de red de señalización por canal común (CCNC) se ocupa de las funciones
MTP y lleva a cabo una función de asignación para ser capaz de distinguir los mensajes
SCCP recibidos y encaminarlos al procesador o proceso correcto. Después que la
SCCP concluye sus funciones se efectúa la transmisión de los mensajes a la TCAP. Por
cada componente de mensaje, la TCAP genera la primitiva asociada y la envía al usua-
rio TC (aplicación).
Por otra parte, para la invocación de operaciones a distancia, los diferentes componen-
tes se transfieren de la aplicación a la TCAP, la cual los agrupa en un solo mensaje
TCAP. Los servicios sin conexión SCCP son invocados y el mensaje TCAP es insertado
en un mensaje sin conexión SCCP, el cual es transmitido a la MTP.
Recursos TCAP
• Bloque de control de transacción
Un Bloque de control de transacción (TCB) es una unidad de memoria que alma-
cena información relacionada con transacción todo el tiempo que dure la transac-
ción. El TCB contiene una parte específica de TCAP para almacenar en ella
cualquier información transitoria durante el tiempo que se extienda un diálogo (p.ej.,
identidades de transacción locales y distantes).
• Identidad de transacción
La identidad de transacción es un identificador que es asignado por la subcapa de
transacción y que permite a la TCAP asociar los mensajes recibidos a las transac-
ciones. La administración de identidad de transacción tiene la función de adminis-
trar todas las identidades de transacción.
• Unidad de datos de protocolo
La Unidad de datos de protocolo (PDU) transporta información de usuario entre los
distintos niveles de la pila de protocolos CCS7, y en particular entre la SCCP y la
TCAP. La aplicación PDU (APDU) transporta información de usuario entre la TCAP
y las aplicaciones.
20 A30808-X3245-X516-1-7818
(TCAP)
5 Formatos de mensajes
Sentido de transmisión
Unidad de señalización de mensajes
B F
F BSN I FSN I LI SIO SIF CK F
B B
Mensaje SCCP
Etiqueta de Tipo de Parte obligatoria Parte obligatoria Parte opcional

encaminamien- mensaje fija variable
to
Mensaje TCAP
Tipo de Longitud total Elemento(s) Etiqueta Longitud Elemento(s) Etiqueta(s) de Longitud Componente (s)
mensaje de mensaje de información de diálogo de información componentes de mensaje
Parte transacción Parte diálogo Parte componente

de mensaje
Bandera Indicador de longitud
BSN Número de secuencia hacia atrás SIO Octeto de información de señalización
BIB Bit indicador hacia atrás SIF Campo de información de señalización
FSN Número de secuencia hacia atrás
Fig. 5.1 Inserción del mensaje TCAP en la unidad de señalización de

mensajes
La construcción de los mensajes TCAP, como se explicara anteriormente, se ajusta a

determinadas reglas que tienen la finalidad de definir las distintas partes obligatorias y
opcionales así como sus parámetros.
El mensaje TCAP se inserta en un mensaje SCCP (sin conexión) a su vez encerrado
por información de control de protocolo MTP (Fig. 5.1). Esta estructura total de datos,
la unidad de señalización de mensajes, es es transmitida más tarde entre dos puntos
de señalización.
A30808-X3245-X516-1-7818 21
(TCAP)
5.1 Unidad de señalización de mensajes

La unidad de señalización de mensajes es una estructura común para la transmisión de
datos de usuario, compuesta de las siguientes partes obligatorias:
• Bandera
La bandera alinea las unidades de señalización.
• Número de secuencia hacia atrás
El BSN se emplea como un portador de acuse de recibo dentro del contexto del
control de errores.
• Bit indicador hacia atrás
Con el BIB, se pide una nueva transmisión de las unidades de señalización defec-
tuosas con la finalidad de corregir los errores.
• Número de secuencia hacia adelante
A cada unidad de señalización a ser transmitida se le asigna consecutivamente un
FSN. Este se emplea del lado de recepción para supervisar el orden correcto de
las unidades de señalización y como protección contra errores de transmisión.
• Bit indicador hacia adelante
El FIB indica si se trata del primer envío de la unidad de señalización o de una re-
transmisión con fines de corrección de error.
• Indicador de longitud
El LI indica la cantidad de octetos incluidos entre el campo LI y el campo de bit de
verificación. El valor LI también indica la clase de unidad de señalización involucra-
da.
• Octeto de información de señalización
El SIO contiene el indicador de servicio indicativo del usuario MTP así como el in-
dicador de red indicativo de tráfico nacional o internacional.
• Campo de información de señalización
El SIF contiene los datos de usuario realmente activos, incluida una dirección de
destino, a la cual se ha de transferir el mensaje.
• Bits de verificación
Los CK se forman del lado de transmisión sobre la base del contenido de la unidad
de señalización de mensajes, permitiendo al lado de recepción determinar si la uni-
dad de señalización fue transferida sin errores.
5.2 Mensaje SCCP

El mensaje SCCP contiene las partes siguientes
• Etiqueta de encaminamiento
La etiqueta de encaminamiento (MTP) provee información de encaminamiento a la
MTP permitiéndole a esta última encaminar la unidad de señalización de mensajes
hacia su destino. La etiqueta contiene los parámetros siguientes.
– El código de punto de destino identifica el punto de señalización del destino de

mensaje en una red CCS7 específica.
– El código de punto de origen caracteriza el punto de señalización que envía la
unidad de señalización de mensajes.
– La selección de enlace de señalización es un identificador que caracteriza el en-
lace de señalización a ser usado para transportar el mensaje.
22 A30808-X3245-X516-1-7818
(TCAP)
• Tipo de mensaje
El tipo de mensaje define la función y el formato del mensaje SCCP. Para la trans-
ferencia de mensaje TCAP sólo se usan los mensajes sin conexión SCCP, o sea,
los mensajes ’unitdata’ y ’unitdata service’.
• Parte obligatoria fija
La parte obligatoria fija contiene todos los parámetros de mensaje con una longitud
fija y cuya presencia se requiere para un cierto tipo de mensaje. Por ejemplo, la cla-
se de protocolo es un parámetro obligatorio con una longitud fija para el mensaje
unitdata.
• Parte obligatoria variable
La parte obligatoria variable contiene todos los parámetros de mensaje con una lon-
gitud variable que tienen que estar presentes para un cierto tipo de mensaje. Por
ejemplo, la dirección de parte llamada es un parámetro obligatorio con una longitud
variable para el mensaje unitdata.
• Parte opcional
La parte opcional contiene todos los parámetros independientes de mensaje e in-
formación de usuario SCCP (p.ej., mensaje TCAP).
5.3 Mensaje TCAP

El mensaje TCAP consta de tres partes:
– de la parte transacción, que contiene elementos de información empleados por la
subcapa de transacción (control de asociación)
– de la parte diálogo, que contiene elementos de información empleados para nego-
ciación de contexto de aplicación y para transferencia de información suplementaria
– de la parte message, que contiene elementos de información empleados por la sub-
capa de componente
Todos los elementos de información incluidos en el mensaje TCAP tienen igual estruc-
tura y se componen de los campos siguientes:
• Etiqueta
La etiqueta distingue entre tipos de datos y determina cómo interpretar el contenido.
La etiqueta contiene las partes siguientes:
– la clase de etiqueta
– la forma, es decir, una primitiva (el contenido es un valor solamente) o un cons-
tructor (el contenido se compone de otros elementos de información)
– el tipo de etiqueta
• Indicador de longitud
El indicador de longitud denota el número de octetos ocupados por el contenido. Se-
gún la longitud se distingue entre las siguientes formas de indicador de longitud:
– la forma corta, si la longitud del contenido es menor que 128 octetos
– la forma larga, si la longitud del contenido es mayor que 128 octetos
– la forma indefinida, si no es posible determinar la longitud del contenido (en este
caso, se emplea un indicador especial de fin de contenido, para marcar el fin del
elemento de información).
• Contenido
El campo de contenido contiene la información real a ser portada por el elemento
de información.
De esta manera, un mensaje TCAP se considera un elemento de información de
constructor simple que tiene una etiqueta (tipo de mensaje), un indicador de longi-
A30808-X3245-X516-1-7818 23
(TCAP)
tud de mensaje total, y un campo de contenido que contiene uno u otros más ele-
mentos de información.
5.3.1 Parte transacción

Etiqueta (tipo de mensaje)
La etiqueta distingue un mensaje TCAP de otro y define la función del mensaje. Según
la estructura de una etiqueta, el campo de tipo de mensajes se compone de tres partes,
es decir, del tipo de clase, de forma, y del mensaje TCAP mismo.
Como se ha indicado anteriormente, se emplean los siguientes mensajes TCAP:
– UNI
– BEGIN
– CONTINUE
– END
– ABORT
Indicador de longitud (longitud de mensaje total)

La longitud de mensaje total contiene la cantidad de octetos en el mensaje TCAP. En
un entorno de Libro Blanco SCCP, el mensaje TCAP puede contener hasta 2048 octe-
tos debido a la capacidad de segmentación/reensamblado de la SCCP.
Contenido (elementos de información de transacción)

Los elementos de información de transacción son los parámetros relacionados con
transacción. Estos se componen de una etiqueta (nombre de parámetro), de un indica-
dor de longitud, y de un contenido (valor de parámetro).
No obstante, sólo existen elementos de información de transacción para un diálogo es-
tructurado. Esto implica que el mensaje TCAP ’UNI’ no tiene ningún elemento de infor-
mación de transacción.
Se incluyen los siguientes elementos de información de transacción, según la función
de mensaje
• ID de transacción de origen
Este es un identificador correlacionado a una transacción del lado de origen del
mensaje. Este parámetro es obligatorio para mensajes de ’begin’ (comenzar) y ’con-
tinue’ (continuar).
• ID de transacción de destino
Este es el identificador correlacionado a una transacción del lado de destino del
mensaje. Este parámetro es obligatorio para mensajes de ’continue’, ’end’ (finalizar)
y ’abort’ (cancelación anormal).
• Causa de cancelación anormal de proveedor ’P-abort’
Este parámetro define la razón de una cancelación anormal por la subcapa de tran-
sacción (p.ej., tipo de mensaje o ID de transacción no reconocidos, limitaciones de
recursos). Este parámetro es obligatorio sólo para mensaje ’provider abort’.
5.3.2 Parte diálogo

Etiqueta de diálogo
La etiqueta de diálogo identifica una parte diálogo.
24 A30808-X3245-X516-1-7818
(TCAP)
Longitud
El campo de longitud especifica la cantidad de octetos contenida en la parte diálogo.
(Diálogo) elemento(s) de información

El contenido de la parte diálogo se compone de un tipo externo que contiene una unidad
de datos de protocolo de diálogo o información de usuario. La construcción de ese con-
tenido es realizada mediante los siguientes elementos de información.
• Diálogo estructurado (obligatorio)
La referencia directa identifica la sintaxis de la unidad de datos del protocolo de con-
trol de diálogo o de la información de usuario. Por ejemplo, cuando el contenido
contiene información de usuario es posible que la referencia directa especifique una
sintaxis de parte aplicación móvil.
• Referencia indirecta (opcional)
La referencia indirecta puede especificar las reglas de codificación. Actualmente
sólo se emplean las reglas de codificación básica.
• Codificación tipo ASN.1 (obligatorio)
El tipo de codificación ASN.1 especifica el contenido en este momento como tipo
ASN.1 simple.
• Unidad de datos de protocolo de control de diálogo o información de usuario (obli-
gatorio)
La unidad de datos del protocolo de control de diálogo contiene información de aso-
ciación necesaria para el manejo del control de diálogo. La información de usuario
puede estar compuesta, por ejemplo, de la información de parte aplicación móvil.
5.3.3 Parte componente de mensaje

La parte componente de mensaje es un elemento de información opcional, compuesto
de etiqueta de componente, de longitud, y de uno o más componentes. Cada compo-
nente constituye una secuencia de elementos de información (parámetros).
Etiqueta de componente
La etiqueta de componente es un identificador codificado fijo que anuncia el comienzo
de la parte componente de mensaje.
Longitud
El campo de longitud especifica la cantidad de octetos contenido en la parte componen-
te de mensaje.
Componente(s) de mensaje (elementos de información)

Cada componente de mensaje se compone de las partes siguientes.
• Tipo de componente
El tipo de componente distingue los componentes entre sí y define la función de los
mismos.
Existen los componentes siguientes:
– invoke (invocar)
– return result last (retornar resultado final)
– return result not last (retornar resultado no-final)
– return error (retornar error)
– reject (rechazar).
A30808-X3245-X516-1-7818 25
(TCAP)
• Longitud de componente
La longitud de componente especifica la cantidad de octetos que el componente
ocupa.
• Elemento(s) de información
El contenido de cada componente se compone de un número de elementos de in-
formación (o sea, parámetros). Cada parámetro se caracteriza por su tipo, longitud
y valor.
Según el tipo de componente, se incluyen los elementos de información siguientes:
– invoke ID (ID de invocación)
– linked ID (ID asociada)
– código de operación
– etiqueta de secuencia
– código de error
– código de problema
– parámetros (información de usuario suplementaria).
26 A30808-X3245-X516-1-7818
(TCAP)
6 Funciones TCAP
6.1 Manejo de componentes

La función de manejo de componentes abarca todas las tareas encargadas del inter-
cambio de componentes entre la TCAP y sus aplicaciones.
Manejo de operaciones
El manejo de operaciones apoya el concepto de operaciones distantes. Esta función
comprende todas las acciones relacionadas con la invocación de operación (o sea, co-
mienzo, fin) y la recepción de mensajes de fructífero/infructuoso.
Cada operación es identificada por una ID de invocación y, en ciertos casos, se permi-
ten operaciones combinadas. Estas operaciones son identificadas más tarde por una
ID asociada. Además, la ID de invocación hace posible que esta aplicación tenga una
cantidad limitada de invocaciones de operación activas simultáneamente dentro del
mismo diálogo.
Idle
TC_Invoke req
TC_U_Cancel req
TC_Continue req
TC_U_Cancel req
TC_U_Cancel req
TC_(U/L/R)_Reject req/ind
Operación Rechazo
TC_L_Cancel ind
pendiente pendiente
ResultL received
Error received
TC_Begin req Error rejected

TC_Continue req ResultL rejected
Operation ResultNL rejected
Sent
Invoke linked operation

Result NL received
Fig. 6.1 Máquina de estado de componentes para clases de operación 1, 2 y 3
A30808-X3245-X516-1-7818 27
(TCAP)
El manejo de operación apoya el concepto de operaciones distantes. Esta función com-

prende todas las acciones relacionadas con la invocación de operación (o sea, arran-
que, fin) y la recepción de avisos de fructífero/infructuoso.
Cada operación es identificada por una ID de invocación y, en algunos casos, se per-
miten operaciones combinadas. Estas operaciones son identificadas más tarde por una
ID asociada. Además, la ID de invocación hace posible que esta aplicación tenga una
cantidad limitada de invocaciones de operación activas simultáneamente dentro del
mismo diálogo.
Correlación de componentes
La correlación de componentes es la asociación de una respuesta recibida a una ope-
ración previamente invocada. La asociación se basa en la ID de invocación, la cual po-
sibilita además que la TCAP pueda correlacionar la invocación de operación con el
temporizador de operación que expira y con cualquier posible rechazo de componente.
Máquina de estado de componentes

La máquina de estado de componentes es un mecanismo que acopla eventos (p.ej.,
recibiendo una primitiva) a transiciones de estado. Se provee una máquina de estado
solamente del lado de transmisión, por cada invocación de operación.
Se pueden disparar transiciones de estado por los eventos siguientes:
– recepción de primitivas de la aplicación local
– recepción de componentes en un mensaje TCAP
– expiración de TCAP locales.
Estos eventos causan transiciones de estado. La máquina de estado de componentes,
empleada sólo para diálogos estructurados (clases 1, 2 y 3), puede tener uno de los es-
tados siguientes (Fig. 6.1):
– reposo
– operación pendiente
– operación enviada
– rechazo pendiente.
La máquina de estado de componentes se encuentra normalmente en reposo. A la re-
cepción de sólo una TC_invoke request, se asigna una máquina de estado y su estado
de operación se ajusta a ’operación pendiente’. Cuando la aplicación cancela la opera-
ción pendiente, la máquina de estado se pone en reposo otra vez.
Se transmite una operación pendiente dentro de un mensaje TCAP tras recibirse la pri-
mitiva de petición de manejo de diálogo apropiada (p.ej., TC_continue request). Más
tarde el estado de operación se ajusta a ’operación enviada’.
Mientras que la TCAP reciba las partes no-final de un resultado (resultNL) o las invoca-
ciones para operaciones combinadas, la máquina de estado no es afectada. Sólo en los
casos siguientes cambia el estado de operación.
• Los eventos a continuación conducen a que la máquina de estado pase a reposo:

– Cancelación de la operación por la petición (TC_U_cancel request).
– Rechazo de la operación bien por la aplicación bien por la entidad TCAP local o
distante.
– Expiración del temporizador de supervisión y la TCAP informa a la aplicación
(TC_L_cancel indication). Este es el caso normal para las clases 2 y 3. La expi-
ración de temporizador para clase 1 es un caso de error.
28 A30808-X3245-X516-1-7818
(TCAP)
– Recepción de resultado por la TCAP (clases 1 y 3).

– Recepción de error por la TCAP (clases 1 y 2).
• El estado de operación se ajusta a ’rechazo pendiente’ en los casos siguientes
– Rechazo por la TCAP de componente de error recibido (clases 1 y 2).
– Rechazo por la TCAP de componente de resultado recibido (clases 1 y 3).
– Rechazo por la TCAP de parte no-final recibida de un resultado (clases 1 y 3).
En caso de rechazo pendiente, la TCAP informa a la aplicación y queda en espera
de sus instrucciones. La aplicación pudiera decidirse por:
– cancelar el rechazo pendiente (TC_U_cancel request)
– transmitir el rechazo al extremo distante en mensaje de continuación
(TC_continue request).
Agrupación de componentes
Una aplicación puede transmitir más de un componente a la TCAP con las primitivas de
manejo de componente antes de solicitar la transmisión. Hasta la transmisión, la sub-
capa de componente tiene que almacenar esos componentes.
Facilidad de cancelación
La función de facilidad de cancelación permite que la aplicación o la TCAP anulen ope-
raciones y pongan en reposo la máquina de estado asociada. Además, la aplicación
puede emplear la facilidad de cancelación para anular rechazos pendientes.
Se puede pedir una cancelación de operación en cualquier momento, o sea, antes de
transmitirse la operación o antes de recibirse alguna respuesta final
– Si la operación es cancelada antes de ser transmitida, el componente almacenado
es anulado y la máquina de estado puesta en reposo.
– Si la operación es cancelada antes de recibirse alguna respuesta, la máquina de es-
tado es puesta en reposo y a la TCAP se le ordena ignorar toda posible respuesta
del extremo distante que no esta consciente de la cancelación.
Manejo de rechazo
La función de manejo de rechazo provee a la aplicación y a la subcapa de componente
el mecanismo para rechazar componentes.
La TCAP rechaza componentes por las razones siguientes:
– componente incorrecto (p.ej., parámetro faltante)
– máquina de estado incorrecta
– recepción de un resultado para operaciones de clases 2 y 4
– recepción de un error para operaciones de clases 3 y 4
– operación combinada ilegal.
Manejo de temporizador
Los temporizadores de supervisión de operación son administrados por la función de
manejo de temporizador. La asignación de un temporizador tal a una invocación es so-
licitada por la aplicación.
Un temporizador de supervisión de operación arranca cuando se pide la transmisión. El
temporizador es detenido normalmente cuando se recibir el resultado final o error. Si el
temporizador expira, la TCAP cancela la operación e informa a la aplicación
(TC_L_cancel indication).
A30808-X3245-X516-1-7818 29
(TCAP)
6.2 Manejo de transacción

La función de manejo de transacción permite a una aplicación establecer una asocia-
ción extremo-a-extremo a una aplicación distante. También se la denomina función de
control de asociación.
Diálogo estructurado
La función de subcapa de transacción principal para un diálogo estructurado es man-
tener una máquina de estado de transacción. Las transiciones de estado son dispara-
das por primitivas de transacción (Fig. Fig. 6.1
Antes del comienzo de una transacción, se abre un diálogo entre la aplicación y la
TCAP. Esto significa que se ha elegido una ID de diálogo. La ID es una referencia local
para identificar el diálogo.
• Lado de transmisión (iniciador de diálogo)

En condiciones normales el estado de transacción es “idle” (reposo). Cuando se re-
cibe la primitiva TC_begin request, la TCAP asigna una ID de transacción. Además,
el estado de transacción se ajusta a ’init sent’. En este punto se puede terminar la
transacción localmente por la aplicación o por la TCAP. En este caso, el lado dis-
tante no es informado.
Tras recibirse un mensaje de continuación TCAP del extremo distante, el estado de
transacción se ajusta a ’active’. La aplicación local es capaz ahora de enviar infor-
mación nueva. Además de lo anterior, es posible finalizar la transacción (fin básico
o arreglado de antemano) o efectuar un aborto por la aplicación o por la TCAP.
• Lado de recepción
Cuando la TCAP recibe el mensaje TCAP iniciante para un diálogo estructurado
(comienzo), la TCAP abre un diálogo con el usuario. Además de lo anterior, se asig-
na una máquina de estado de transición y se ajusta su estado a ’init received’.
Es posible una finalización o aborto de la transacción en forma directa por la aplica-
ción. En este caso la máquina de estado es puesta en reposo. Sin embargo, la apli-
cación distante es capaz de devolver información en un mensaje de continuación.
El estado de transacción es ajustado luego a ’active’.
La aplicación distante es capaz ahora de recibir información nueva. También es po-
sible una finalización (fin básico o arreglado de antemano) o un aborto por la apli-
cación o por la TCAP.
30 A30808-X3245-X516-1-7818
(TCAP)
Lado de transmisión Lado de recepción

(iniciador de diálo-
go)
Reposo
TC_Begin req
TC_Begin ind
TC_End req/ind
TC_U_Abort req/ind TC_End req
TC_P_Abort ind TC_U_Abort req
TC_End req/ind
Init TC_U_Abort req/ind Init
enviado TC_P_Abort ind recibido
TC_Continue ind TC_Continue req
Activo
TC_Continue req/ind
Fig. 6.2 Máquina de estado de transacción para diálogo estructurado
Diálogo no estructurado
Para enviar un mensaje unidireccional, la aplicación primero abre un diálogo con la
TCAP. En el lado de recepción, la TCAP comprueba si el componente recibido es una
invocación o un rechazo. Otros componentes son ignorados.
Manejo de situación anormal

Esta función cubre todas las tareas a ser llevadas a cabo en caso de situaciones anor-
males. Entre las situaciones anormales posibles se encuentran.
– No reacción a iniciación de transacción (mensaje comienzo).
– Recepción por la TCAP de mensaje con ID de transacción de destino no asignada.
Si el mensaje contiene la ID de transacción de origen, es posible la devolución de
un mensaje de aborto.
– Recepción por la TCAP de mensaje que no cumpla con el estado de transacción.
Devolución de mensaje de aborto.
– La TCAP detecta limitaciones de recursos al recibo de un mensaje de comienzo.
Devolución de mensaje de aborto.
A30808-X3245-X516-1-7818 31
(TCAP)
Mantenimiento de IDs de transacción

La ID de transacción es una referencia local que hace posible que la TCAP pueda aso-
ciar mensajes concretos a una transacción.
La administración de ID de transacción comprende las tareas siguientes:
– La administración de ID de transacción identifica el proceso que maneja el mensaje
TCAP
– Se provee un mecanismo para reconocer e ignorar mensajes entrantes para tran-
sacciones que no son legales debido a recovery.
– La administración de ID de transacción evita la posible reasignación demasiado rá-
pida de una ID de transacción. Se toma en cuenta un tiempo de bloqueo.
6.3 Manejo de control de diálogo

El manejo de control de diálogo coordina el uso de las unidades de datos del protocolo
de control de diálogo para negociación de contexto de aplicación y transferencia de in-
formación de usuario
• Negociación de contexto de aplicación
El contexto de aplicación es un identificador de objeto único y globalmente conoci-
do, empleado para identificar versiones específicas de determinadas aplicaciones
(p.ej., versión 1 ó 2 de parte aplicación móvil). Ambas entidades de aplicación tie-
nen que convenir en este contexto de aplicación. El procedimiento en cuestión se
denomina negociación de contexto de aplicación y es ejecutado durante el estable-
cimiento de la transacción.
El medio de transporte de esta información es la unidad de datos del protocolo de
control de diálogo, contenida en la porción de diálogo de un mensaje TCAP.
• Transferencia de información de usuario
Una aplicación puede pedir de la TCAP que transfiera información general de usua-
rio dentro de la parte diálogo de un mensaje TCAP. Para hacer esto deberá llevarse
a cabo una negociación de contexto de aplicación.
La información de usuario se puede transmitir entre aplicaciones de las siguientes
maneras.
– La información de usuario se puede añadir a la unidad de datos del protocolo de
control de diálogo durante la negociación de contexto de aplicación.
– La información de usuario se puede poner en la parte diálogo de un mensaje de
aborto, incluso sin negociación de contexto de aplicación (o sea, aborto Libro
Azul).
6.4 Funciones comunes

Mediciones TCAP
Las funciones de medición TCAP administran contadores de tráfico y mantenimiento en
el contenido de mediciones CCS7.
TCAP administra los contadores siguientes para el registro de:
– la cantidad total de mensajes de comienzo, continuación, fin, aborto y unidireccio-
nales enviados por el nodo de red
– la cantidad total de mensajes de comienzo, continuación, fin, aborto y unidireccio-
nales
– la cantidad total de componentes enviados por un nodo de red
– la cantidad total de componentes recibidos por un nodo de red
32 A30808-X3245-X516-1-7818
(TCAP)
– la cantidad total de ejecuciones para mensajes de comienzo, continuación, fin,

aborto y unidireccionales
– la cantidad total de ejecuciones de cortocircuito para mensajes de comienzo, conti-
nuación, fin, aborto y unidireccionales
– la cantidad total de rechazos con un código de problema concreto recibido y gene-
rado
– la cantidad total de rechazos de usuario recibidos y enviados
– la cantidad total de abortos por cortocircuitos con causa de aborto concreta.
Distribución/interfaz de primitivas
Esta función distribuye eventos internos (almacenados en la memoria intermedia de
eventos internos) hacia sus destinos respectivos tomando en cuenta el origen, e invoca
el proceso apropiado para manejar el evento. En particular la TCAP se llama en caso
de los eventos siguientes:
– generación por una aplicación de una primitiva de petición (componente o transac-
ción)
– expiración de temporizador de supervisión TCAP; se envía indicación a la TCAP
– transmisión de mensaje TCAP por la SCCP.
Cortocircuito TCAP en CP
La función de cortocircuito de la TCAP en el CP provee medios para establecer asocia-
ciones entre aplicaciones en el mismo nodo de red sin emplear los servicios de la SCCP
y de la MTP.
Apoyo de servicios de red SCCP

Al usar los servicios sin conexión SCCP la TCAP tiene que transmitir la información si-
guiente a la SCCP.
• Dirección de las partes llamante y llamada
La información de dirección se emplea para construir los parámetros de dirección
en la primitiva petición unitdata.
• Clase de protocolo SCCP y control de secuencia
La aplicación transmite estos datos a la TCAP en las primitivas manejo de diálogo.
Más tarde la TCAP pone la información en la primitiva petición unitdata.
• Mensaje de devolución en caso de error
La aplicación pide la opción de devolución. La TCAP informa más tarde a la SCCP
en la primitiva petición unitdata.
A30808-X3245-X516-1-7818 33
7 Abreviaturas
APDU application protocol data unit unidad de datos de protocolo de aplicación
ASN.1 abstract syntax notation notación de sintaxis abstracta
BIB backward indicator bit bit indicador hacia atrás
BSN backward sequence number número de secuencia hacia atrás
CCS7 common channel signaling network red de señalización por canal común No. 7
CK check bits bits de verificación
FIB forward indicator bit bit indicador hacia adelante
FSN forward sequence number número de secuencia hacia adelante
HLR home location register registro de posiciones propio
IN intelligent network red inteligente
ISP intermediate service part parte servicio intermedio
LI length indicator indicador de longitud
MAP mobile application part parte aplicación móvil
MML man machine language lenguaje hombre-máquina
MSC mobile-services switching center centro de conmutación de los servicios móviles
MTP Message transfer part parte transferencia de mensajes
NSP network service part parte de servicio de red
OMC Operation and Maintenance Center centro de operación y mantenimiento
OSI open system interconnection interconexión de sistema abierto
PDU Protocol data unit unidad de datos de protocolo
ROSE remote operation service element elemento de servicio de operaciones a distancia
SCCP signaling connection control part parte control de la conexión de señalización
SCP service control point punto de control de servicio
SIF Signaling information field campo de información de señalización
SIO Signaling information octet octeto de información de señalización
TC Transaction capabilities capacidades de transacción
TCAP transaction capabilities application part parte aplicación de capacidades de transacción
TCB Transaction control block bloque de control de transacciones
UDTS unidata unidata
UDTS unidata service servicio unidata
VLR visitor location register registro de posiciones de visitantes
34 A30808-X3245-X516-1-7818
Información Parte de aplicación de capacidad de transación
Señalización (TCAP)
8 Palabras clave
B R
bit indicador hacia adelante 22 referencia directa 25
bit indicador hacia atrás 22 referencia indirecta 25
bits de verificación 22 registro de posiciones propio 17
bloque de control de transacción 20
T
C televoto 6
campo de información de señalización 22 tipo de componente 25
causa de cancelación anormal de proveedor 24 tipo de mensaje 23
codificación tipo ASN.1 25 transacción de destino 24
correlación de componentes 28 transacción de origen 24
cortocircuito TCAP 33
U
D unidad de datos de protocolo 20
diálogo estructurado 24, 25, 30 unidad de señalización de estado de enlace 8
diálogo no estructurado 31 unidad de señalización de mensajes 8
unidad de señalización de relleno 8
E
elemento de información de transacción 24
etiqueta de encaminamiento 22
F
facilidad de cancelación 29
fin básico 14
fin organizado de antemano 14
Funciones 27
I
identidad de transacción 20
indicador de longitud 22
M
manejo de operaciones 27
máquina de estado de componentes 28
N
nivel de enlace de datos 8
nivel de red 8
nivel físico 8
número de secuencia hacia adelante 22
número de secuencia hacia atrás 22
O
octeto de información de señalización 22
P
parte obligatoria fija 23
parte obligatoria variable 23
parte opcional 23
A30808-X3245-X516-1-7818 35
36 A30808-X3245-X516-1-7818

Información: Señalización Parte de Aplicación de Capacidad de Transación (TCAP)

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Información: Señalización Parte de Aplicación de Capacidad de Transación (TCAP)

Cargado por

Copyright:

Formatos disponibles

Información

Parte de aplicación de capacidad de

Copyright (C) Siemens AG 1998

Editado por el Grupo Redes de Comunicación Públicas

Reservada la posibilidad de modificaciones técnicas.

3 Estructura de la Parte aplicación de capacidades

Fig. 1.1 Empleo de los servicios TCAP para televoto y actualizaciones de

La Parte aplicación de capacidades de transacción (TCAP) es un protocolo de señali-

conexión no relacionada con circuito (virtual), empleada para intercambiar información

Elemento de red Elemento de red distante

Fig. 2.1 TCAP insertada en la parte pila protocolo de CCS7

lización. Este conjunto de reglas y procedimientos se denomina protocolo de

2.1 Parte transferencia de mensaje

2.2 Parte control de conexión de señalización

2.3 Parte aplicación de capacidades de transacción

– Esta clase se emplea dentro de un diálogo estructurado donde la aplicación espera

2.4 Usuarios TCAP

3 Estructura de la Parte aplicación de capaci-

Fig. 3.1 Estructura de TCAP

La definición de la TCAP según la Recomendación Q.771-Q.774 de la ITU/CCITT men-

en varios resultados menores. El manejador de diálogo maneja todos las primitivas de

3.1 Primitivas de manejo de componentes

3.2 Primitivas de manejo de diálogo

3.3 Mensajes TCAP

ABORT (CANCELACION ANORMAL)

3.4 Flujo de información de un diálogo estructurado

Elemento de red Distante

Local Appli- TCAP TCAP Remote

TC_P_ABORT ind ABORT

Fig. 3.2 Flujo de información para un diálogo estructurado (clase 1 ó 3)

La invocación de operaciones distantes dentro de un diálogo estructurado se puede en-

• Fin organizado de antemano

Funciones de procesamiento de llamadas CP

Parte aplicación capacidades de transacción

Parte control de conexión de señalización

Funciones de procesamiento de llamadas CP

Administración Funciones Parte aplicación de capacidades de transacción

Parte control de conexión de señalización

Fig. 4.1 Implementación de la TCAP

La implementación de la Parte aplicación de capacidades de transacción se efectúa a

Unidad de señalización de mensajes

Etiqueta de Tipo de Parte obligatoria Parte obligatoria Parte opcional

Parte transacción Parte diálogo Parte componente

Fig. 5.1 Inserción del mensaje TCAP en la unidad de señalización de

La construcción de los mensajes TCAP, como se explicara anteriormente, se ajusta a

5.1 Unidad de señalización de mensajes

5.2 Mensaje SCCP

– El código de punto de destino identifica el punto de señalización del destino de

5.3 Mensaje TCAP

5.3.1 Parte transacción

Indicador de longitud (longitud de mensaje total)

Contenido (elementos de información de transacción)

5.3.2 Parte diálogo

(Diálogo) elemento(s) de información

5.3.3 Parte componente de mensaje

Componente(s) de mensaje (elementos de información)

6.1 Manejo de componentes

TC_Begin req Error rejected

Invoke linked operation

Fig. 6.1 Máquina de estado de componentes para clases de operación 1, 2 y 3

El manejo de operación apoya el concepto de operaciones distantes. Esta función com-

Máquina de estado de componentes

• Los eventos a continuación conducen a que la máquina de estado pase a reposo: