DISEÑO DE UN SERVICE CONTROL POINT PARA REDES DIGITALES DE TELEFONIA CELULAR DE PRIMERA GENERACION

Transcripción

1 DISEÑO DE UN SERVICE CONTROL POINT PARA REDES DIGITALES DE TELEFONIA CELULAR DE PRIMERA GENERACION ANDRES BENITO REVOLLO VELEZ PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA DEPARTAMENTO DE ELECTRÓNICA Bogotá D. C., Noviembre de 2004

2 DISEÑO DE UN SERVICE CONTROL POINT PARA REDES DIGITALES DE TELEFONIA CELULAR DE PRIMERA GENERACION ANDRES BENITO REVOLLO VELEZ DIRECTOR Ing. EDGARDO RAFAEL REALES NAJERA PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA DEPARTAMENTO DE ELECTRÓNICA Bogotá D. C., Noviembre de

3 PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA CARRERA DE INGENIERÍA ELECTRÓNICA RECTOR MAGNIFICO: R.P. GERARDO REMOLINA S.J. DECANO ACADÉMICO: Ing. ROBERTO ENRIQUE MONTOYA VILLA DECANO DEL MEDIO UNIVERSITARIO: R.P. ANTONIO JOSÉ SARMIENTO NOVA S.J. DIRECTOR DE CARRERA: Ing. JUAN CARLOS GIRALDO CARVAJAL DIRECTOR DEL PROYECTO: Ing. EDGARDO REALES NAJERA 3

4 ARTICULO 23 DE LA RESOLUCIÓN No. 13 DE JUNIO DE 1946 "La universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral católica y porque los trabajos no contengan ataques o polémicas puramente personales. Antes bien, que se vea en ellos el anhelo de buscar la verdad y la justicia". 4

5 TABLA DE CONTENIDO TABLA DE CONTENIDO...5 LISTA DE FIGURAS...9 LISTA DE TABLAS...11 LISTA DE ANEXOS...12 GLOSARIO...14 INTRODUCCIÓN MARCO TEÓRICO SEÑALIZACIÓN Señalización por canal común (SS7) Componentes del SS N.º Arquitectura del protocolo SS N.º Direccionamiento en SS Nº Descripción Parte de Aplicación Capacidad De Transacción (TCAP) Conceptos Básicos de TCAP Servicio proporcionado por la subcapa componente Componente Diálogo Diálogo no estructurado Diálogo estructurado

6 Correlación de componentes Tratamiento de errores Servicio proporcionado por la subcapa transacción Diálogo no estructurado Diálogo estructurado Servicio proporcionado por TC basadas en un servicio de red sin conexión Primitivas de la Subcapa de componente Manejo del Diálogo Estructurado OPERACIONES PLANTEAMIENTO DEL PROBLEMA Y EVOLUCION DEL PROYECTO CONSIDERACIONES INICIALES Módulo SCP Módulo de Base de Datos METODOLOGÍA INICIAL Módulo SCP Módulo de Base de Datos METODO DEFINITIVO Módulo SCP Módulo de Base de Datos LOGROS ADICIONALES DESARROLLOS E IMPLEMENTACIONES MÓDULO DE SCP

7 3.1.1 Subsistema MTP Subsistema SCCP Subsistema Transaccional Subsistema de Consulta MÓDULO DE BASE DE DATOS Subsistema de Funciones Subsistema de perfiles Subsistema de parámetros Subsistema de Creación de Servicios Subsistema de Mantenimiento ESPECIFICACIONES REQUERIMIENTOS DEL SISTEMA Requerimientos del Módulo SCP Requerimientos del Módulo de Base de Datos Requerimientos de los clientes DESEMPEÑO DEL SISTEMA EVALUACION Y ANALISIS DE RESULTADOS ESTUDIO PRELIMINAR DE LA RED DE SEÑALIZACIÓN Diagrama de Red

8 5.1.2 Especificaciones Elementos de Red Servicios disponibles Transacciones PRUEBAS RECOMENDACIONES ITU-T Pruebas de la Capa MTP Pruebas de control de estado de Enlace PRUEBAS FUNCIÓNALES Configuración del Ambiente Parámetros de la Prueba Resultados LIMITACIONES Y POSIBLES MEJORAS LIMITACIONES DEL SISTEMA POSIBLES MEJORAS CONCLUSIONES BIBLIOGRAFÍA Y FUENTES DE INFORMACIÓN

9 LISTA DE FIGURAS FIGURA 1. MODELO PROTOCOLO SS Nº FIGURA 2. TIPOS DE ETIQUETA DE MENSAJE SS Nº FIGURA 3. MENSAJES SS FIGURA 4. FIGURA 5. CAPAS DE SS7 EN TRANSACCIONES...31 CAPAS DE APLICACIÓN TCAP...33 FIGURA 6. DIAGRAMA EN BLOQUES DEL SISTEMA...62 FIGURA 7. ENCABEZAMIENTO MTP...63 FIGURA 8. DISTRIBUCIÓN DE MENSAJES...64 FIGURA 9. FIGURA 10. FIGURA 11. FIGURA 12. PARÁMETROS MTP ARCHIVO CONFIG.TXT...66 SUBSISTEMA MTP DENTRO DE LA INTERFAZ DE USUARIO.67 INFORMACIÓN DE SCCP EN INTERFAZ DE USUARIO...70 ESTRUCTURA MÓDULO BASE DE DATOS...73 FIGURA 13. MODELO DE RELACION ENTRE LAS TABLAS...75 FIGURA 14. AMBIENTE GENERAL SQL DESIGNER...77 FIGURA 15. CONFIGURACIÓN DE PARÁMETROS...78 FIGURA 16. CLIENTE DE ADMINISTRACION DE BASE DE DATOS

10 FIGURA 17. CONTROL DE ACCESO...79 FIGURA 18. FIGURA 19. FIGURA 20. INFORMACIÓN SUMINISTRADA POR EL CLIENTE...80 PROPIEDADES DE BASE DE DATOS...80 DESEMPEÑO DEL MÓDULO SCP...83 FIGURA 21. UTILIZACIÓN LOG DE TRANSACCIONES...84 FIGURA 22. UTILIZACIÓN ESPACIO FÍSICO SERVIDOR DE BASE DE DATOS...85 FIGURA 23. FIGURA 24. FIGURA 25. DIAGRAMA DE RED DE SEÑALIZACIÓN...87 CONFIGURACIÓN DE PRUEBA NIVEL MTP...90 INICIALIZACIÓN DEL SISTEMA...91 FIGURA 26. MENSAJES DE MANTENIMIENTO...91 FIGURA 27. FIGURA 28. MENSAJE ENVIADO DESDE EL SCP...92 RESPUESTA OBTENIDA POR LA MSC ERICSSON...93 FIGURA 29. MENSAJE DE PRUEBAS DE ENLACE...94 FIGURA 30. SECUENCIA MENSAJES DE ESTADO...94 FIGURA 31. MENSAJE DE RESPUESTA...95 FIGURA 32. DIAGRAMA DE MENSAJESPRUEBA FUNCIÓNAL

11 LISTA DE TABLAS TABLA 1. Primitivas para el tratamiento de diálogo TABLA 2. Primitivas para el tratamiento de componentes TABLA 3. Primitivas TC-COMIENZO TABLA 4. Primitivas TC-CONTINUACIÓN TABLA 5. Primitivas TC-FINALIZACIÓN TABLA 6. Primitivas TC-NOTIFICACIÓN TABLA 7. Primitivas TC-INVOCACIÓN TABLA 8. Primitivas TC-RESULTADO TABLA 9. Primitivas TC-U-RECHAZO TABLA 10. Requerimientos Módulo SCP TABLA 11. Especificaciones Módulo Base de Datos TABLA 12. Configuración de Memoria Servidor de Base de Datos 11

12 LISTA DE ANEXOS ANEXO A. Análisis estado Actual y Futuro Red de Señalización ANEXO B. Procedimientos para manejo de MTP ANEXO C. Configuración de Parámetros de Señalización Central Ericsson ANEXO D. Procedimiento BuildSCCP ANEXO E. Función SCCPDecode ANEXO F. Procedimiento SCCPReadStatus ANEXO G. Procedimiento SCCPSubSystemConf ANEXO H. Procedimiento SCCPConfig ANEXO I. Procedimiento ProcessSCCPMsgReceive ANEXO J. Subsistema de configuración ANEXO K. Procedimiento ThreadSCCPMsgReceive ANEXO L. Procedimiento ProcessMsg 12

13 ANEXO M. Mensajes PCCS3 ANEXO N. Procedimiento TCAPDecode ANEXO O. Procedimiento IS41Decode ANEXO Q. Procedimiento ProcessOCANOTMsg ANEXO R. Clases y Definiciones Módulo de Base de Datos ANEXO S. Procedimientos y Funciones Módulo de Base de Datos ANEXO T. Diagrama Entidad Relación Módulo Base de Datos ANEXO U. Monitoreo Analizador Prueba Funcional ANEXO V. Rastreo a Nivel de Central Prueba Funcional 13

14 GLOSARIO Central Telefónica: Conjunto de dispositivos de transporte de tráfico, de etapas de conmutación, de medios de control y señalización, y de otras unidades funcionales de un nodo de la red, que permite la interconexión de líneas de abonados, circuitos de telecomunicaciones u otras unidades funciónales, según lo requieran los usuarios individuales. Conmutación: Proceso que consiste en asociar temporalmente equipos funcionales, canales de transmisión o circuitos de telecomunicación para prestar un servicio deseado de telecomunicación. Completación: Establecimiento y utilización de una cadena de conexión completa, tras una tentativa de llamada. Conversación: Intercambio de información entre terminales. Costo de Interconexión: Es el valor de las inversiones y gastos necesarios para interconectar las redes, a partir del punto de interconexión hacia la red del operador solicitante. Se incluyen, entre otros, los equipos de interconexión, los medios de acceso, los equipos, sistemas, soportes lógicos, dispositivos y órganos de conexión. CRT: Comisión de Regulación de Telecomunicaciones. 14

15 Intento de llamada: Secuencia de operaciones efectuadas por el usuario de una red de telecomunicación para tratar de comunicar con el usuario, terminal o servicio deseado. Interconexión: Es la vinculación de recursos físicos y soportes lógicos, incluidas las instalaciones esenciales necesarias, para permitir el interfuncionamiento de las redes y la interoperabilidad de servicios de telecomunicaciones. Interconexión Directa: Es la interconexión entre las redes de dos operadores que comparten al menos un punto de interconexión entre ellas con el objeto de lograr el interfunciónamiento de las redes conectadas y la interoperabilidad de los servicios. Interconexión indirecta: Es la interconexión que permite a cualquiera de los operadores interconectados cursar el tráfico de otros operadores a la red del operador interconectante, siempre que no se contravenga el reglamento para cada servicio. El solo servicio portador entre dos redes no se considera interconexión indirecta. Nodo: Es el elemento de red, ya sea de acceso o de conmutación, que permite recibir y reenrutar las comunicaciones. Nodo de interconexión: Es el nodo vinculado directamente con el punto de interconexión. Operador: Es la persona jurídica pública, mixta o privada que es responsable de la gestión de un servicio de telecomunicaciones en virtud de autorización, licencia o concesión, o por ministerio de la ley. Esta Resolución se refiere indistintamente al operador y al concesionario. 15

16 Proceso de Facturación: Es la etapa en la que se realiza el conjunto de actividades mediante la cual se generan las facturas correspondientes a los consumos de los usuarios o suscriptores. Proceso de Tarificación: Es la etapa en la que se realiza el conjunto de actividades mediante la cual se le aplica un valor monetario a los consumos medidos en el proceso de tasación. Proceso de Tasación: Es la etapa en la que se realiza el conjunto de actividades mediante la cual se mide el consumo de los usuarios o suscriptores. Punto de interconexión: Es el punto físico en donde se efectúa la conexión entre dos redes, para permitir su interfuncionamiento y la interoperabilidad de los servicios que éstas soportan. Servicios suplementarios: Son aquellos servicios suministrados por una red de TPBC, además de su servicio o servicios básicos, entre otros los siguientes: conferencia entre tres, llamada en espera, marcación abreviada, despertador automático, transferencia de llamada, conexión sin marcar y código secreto. Suscriptor: Es la persona natural o jurídica con la cual un operador ha celebrado un contrato de condiciones uniformes de servicios públicos. Tarjeta Prepago: Es cualquier medio impreso o electrónico que, mediante el uso de claves de acceso u otros sistemas de identificación, permite a un usuario acceder a una capacidad predeterminada de servicios de telecomunicaciones que ha adquirido en forma anticipada. TMC: Telefonía Móvil Celular. 16

17 UIT: Unión Internacional de Telecomunicaciones. Desconexión: Interrupción temporal, física o lógica, total o parcial del funcionamiento de equipos o medios de transmisión necesarios para la interconexión. Elemento de red: Es una facilidad o equipo utilizado en la prestación de un servicio de telecomunicaciones e individualizado a los fines de la interconexión. Este término incluye características, funciones y capacidades como, por ejemplo, acceso local a abonados, conmutación, bases de datos, sistemas de transmisión, sistemas de señalización, información necesaria para la facturación o cobranza, encaminamiento, entre otros. Radiobase: Una o más transmisores o receptores, o una combinación de transmisores y receptores, incluyendo las instalaciones accesorias, necesarias para asegurar la prestación del servicio de telefonía móvil celular. BCSM: Modelo de estados de llamada básica. CCAF: Función de agente de control de llamada. CCF: Función de control de llamada. CLI: Identificación de la línea llamante. DP: Punto de detección. IP: Periférico inteligente. 17

18 NAP: Punto de acceso a la red. PE: Entidad física. PIC: Punto en llamada. RI: Red inteligente. RTPC: Red telefónica pública conmutada. SCF: Función de control de servicio. SCF(o): Función de control de servicio de red de origen. SCF(t): Función de control de servicio de red de terminación. SCP: Punto de control de servicio (service control point). SDF: Función de datos de servicio (service data function). SDF(o): Función de datos de servicio de red de origen. SDF(t) : Función de datos de servicio de red de terminación. SDP: Punto de datos de servicio (service data point). SIB: Bloque de edificación independiente del servicio. 18

19 SN: Nodo de servicio (service node). SSCP: Punto de conmutación y control de servicio (service switching and control point). SSP: Punto de conmutación de servicio (service switching point). TDP: Punto de detección de activador (trigger detection point). 19

20 INTRODUCCIÓN Actualmente estamos viviendo, en el mundo de las comunicaciones, un incremento en la importancia de la señalización. Los principales factores que favorecen este incremento pueden clasificarse en dos grandes grupos: en uno están los derivados de la demanda por parte de los usuarios de nuevos servicios, que dan origen a nuevos tipos de tráfico de señalización y, en el otro, los derivados de la implantación de determinados mecanismos con objeto de optimizar el uso y facilitar la gestión de los recursos disponibles de red. Con esta tendencia, las redes de comunicación están enfrentando un incremento del número de mensajes por cada conexión establecida para los servicios de usuario, repercutiendo en todos los tramos de la red debido a la mayor complejidad de los nuevos servicios y a la distribución de las funciones en la red. Este incremento, por otra parte, no se da uniformemente a través de la red, sino que se presenta como concentraciones de tráfico de señalización en algunos centros, fundamentalmente en aquellos donde se ubican las bases de datos a las cuales se debe acceder para prestar los servicios (SCP s). Vemos entonces en los sistemas de comunicación la coexistencia de dos tipos de tráfico: de información y de señalización, con tratamientos y características distintos (modo circuito uno y modo paquete el otro), por lo que se debe definir si lo conveniente es utilizar equipos de red que administren la mezcla de tráfico o, si por el contrario, lo conveniente es utilizar equipos especializados en el tratamiento de cada tipo de tráfico, evitando las interrelaciones que el tratamiento de un tipo de tráfico pueda tener sobre la capacidad de tratamiento del otro. 20

21 Un punto de control de servicios (SCP) contiene la información necesaria para proveer servicios de inteligencia de red, con lo cual la implementación de servicios y la concentración de mensajes de señalización orientada a la prestación de dichos servicios se separa de la información de voz. Este SCP está conectado con la red de conmutación a través de una red de señalización. El presente trabajo se centra en el diseño de un punto de control de servicios para una red de señalización existente y su implementación dentro de la misma, incluyendo la interacción con la red de conmutación. Para realizar este diseño se plantea un estudio previo de los conceptos básicos de señalización por canal común obteniendo con esto las herramientas de diagnostico que nos permitan estructurar el proyecto. El sistema planteado comprende 2 grandes partes: la primera se encargará del proceso de conexión con la red de señalización, interpretando los mensajes provenientes de la misma y realizando la codificación de las respuestas. De igual forma monitoreará las conexiones de la red de señalización; para esto se utilizará la información obtenida en el estudio del sistema de señalización número 7. La segunda parte consiste en la base de datos relacional que contiene la parte de inteligencia contenida en el SCP [5]. De igual forma se desarrollará una interfaz para usuario final con el fin tener acceso a la configuración del SCP, es decir, la incorporación o modificación de servicios. La solución aquí planteada se convierte en un paso inicial para la incorporación de inteligencia de red en un sistema de comunicación, ya que a partir del SCP se puede acceder directamente a los mensajes de señalización, permitiendo la integración de redes de voz y datos a un bajo costo. Adicionalmente, este tipo de soluciones solventa los inconvenientes financieros de aplicación de nuevos servicios sobre redes existentes. 21

22 1 MARCO TEÓRICO Este trabajo se basa en el tráfico de señalización por canal común y de las transacciones del involucradas en los procesos de comunicación; para una mejor comprensión del mismo a continuación se presenta una resumen de los conceptos utilizados para la elaboración del proyecto. 1.1 Señalización El concepto de señalización se refiere al intercambio de información entre los componentes de una llamada para proporcionar o mantener un servicio Señalización por canal común (SS7) La señalización por canal común es un método de señalización que mensajes con direcciones para poder transportar información de señalización sobre cualquier canal. Está normalizada bajo la Q.700 de marzo de 1993 por la ITU-T, donde se establece que este sistema de señalización satisface las exigencias de la señalización de control de las llamadas para servicios de telecomunicaciones tales como telefonía y transmisión de datos con conmutación de circuitos. Puede utilizarse también como un sistema fiable para la transferencia de otros tipos de información entre centrales y centros especializados enredes de telecomunicaciones (por ejemplo, para fines de gestión y mantenimiento). Por consiguiente, puede utilizarse para aplicaciones múltiples tanto en redes especializadas para servicios específicos como en redes capaces de ofrecer 22

23 múltiples servicios. Se pretende que este sistema de señalización sea aplicable en redes internacionales y nacionales.[19] Bajo estos preceptos tomamos como la definición más exacta del SS7 la formulada por la ITU-T que reza lo siguiente: La señalización por canal común es un método de señalización en el cual un solo canal transfiere, por medio de mensajes etiquetados, información de señalización relativa a varios circuitos y otras informaciones tales como la gestión de la red. Se puede considerar la señalización por canal común como una forma de comunicación de datos que está especializada para varios tipos de transferencia de información y de señalización entre procesadores en las redes de telecomunicaciones. [19] Componentes del SS N.º 7 Dado que el sistema de señalización utiliza enlaces de señalización para la transferencia de mensajes de señalización entre centrales u otros nodos de la red de telecomunicaciones servidos por este sistema, tiene una arquitectura bien definida y normalizada. El conjunto global de todos estos enlaces de señalización se conoce como Red de Señalización. La red de señalización es la agrupación de cada uno de los nodos de conmutación y procesos interconectados a través de enlaces de transmisión que contiene la información y configuración necesaria para interpretar y transmitir los mensajes propios (datos) del SS N. 7, para esto se crean sobre los enlaces de transmisión unos enlaces de datos conocidos como enlaces de señalización y los nodos de pasan a ser puntos de señalización. Los componentes que pertenecen a una red de señalización son los siguientes: 23

24 Puntos de Señalización (SSP): Se define como la unidad básica dentro de la red de señalización; generalmente esta constituido por las centrales de conmutación, tamdens o equipos con capacidad para interpretar mensajes SS N.º 7. El punto de señalización es físicamente un nodo donde se inicia o terminan los procesos propios de una llamada (establecimiento, mantenimiento, etc). Enlace de Señalización (SSL): Son el medio utilizado para la transferencia de la información de señalización entre dos puntos de señalización. Punto de transferencia de Señalización (STP): Los puntos de transferencia de señalización tienen como objetivo el enrutamiento de los mensajes a su correcto destino, es decir a diferencia de los puntos de señalización, un STP no es un punto origen ni destino sino un punto intermedio que sirve de gateway a dos o más links de señalización. Punto de Control de Señalización (SCP): El punto de control de señalización corresponde a la base de datos donde se almacenan la información y la inteligencia necesaria para el procesamiento avanzado de llamadas. Se convierte en un originador/receptor de mensajes de señalización y tiene la capacidad de modificar el contenido de un mensaje y reenrutarlo hacia un SSP. El SCP también se conoce como punto de control de servicios. Las convenciones recomendadas por la ITU-T en las normas Q.700 1, Q y 1 " 3974/:.. 3, ,/080,,. 3H /0 %% 2 " :3. 43, /0,5,79097, ,/02038, 08/ ,/080,,. 3H 24

25 Q son las siguientes: PUNTO DE SEÑA LIZACION-SSP PUNTO DE TRANSFERENCIA DE SEÑALIZACION-STP PUNTO DE CONTROL DE SEÑALIZA CION-SCP Arquitectura del protocolo SS N.º 7 El protocolo SS N.º 7 se modela a partir de capas (Figura 1). Desde el punto de vista de una determinada capa, las capas inferiores ofrecen un «servicio de transferencia» con características específicas. La forma en que se realiza una capa inferior es indiferente para la capa superior siguiente. Del mismo modo, las capas inferiores no son afectadas por el significado de la información procedente de capas superiores ni por las razones de esta transferencia. Figura 1. Modelo Protocolo SS Nº. 7 3 " 897:.9:7,/0,70//080,,. 3 25

26 Los primeros tres (3) niveles dentro del modelo corresponden a la parte de transferencia de mensaje o MTP. En conjunto estos niveles son los responsables de llevar el mensaje desde su origen hasta su destino. El nivel 1 de MTP es el encargado de definir las características físicas y eléctricas relacionadas con los enlaces de la red de señalización. El nivel 2 de MTP maneja lo referente a la transferencia del mensaje de un nodo a otro y debe garantizar que dicha transferencia sea confiable; este nivel cuenta con mecanismos de detección de errores, control de flujo y revisión de secuencia normalizados bajo la norma Q de la ITU-T. El nivel 3 tiene la responsabilidad de decidir cuál de los posibles caminos será el que deben seguir los mensajes para llegar a su destino, es decir, tiene las funciones de direccionamiento, ruteo alterno y control de tráfico. Subiendo en el modelo encontramos tres capas alternas, que corresponden básicamente a la orientación de los mensajes y al tipo de conexión. La descripción de estas capas es la siguiente: Parte de Usuario ISDN (ISUP): Se ocupa básicamente del control en el establecimiento y terminación de llamadas telefónicas entre dos SSCP. Es un protocolo orientado a conexión, lo que significa que se permite la conexión entre dos usuarios. Durante la misma la regula y cuando ésta termina se encarga de la liberación. Este protocolo se encuentra regulado en la ITU-T a través de la norma Q Parte de Usuario de Telefonía (TUP): este protocolo esta regulado a través de las normas Q y Q de la ITU-T. Define las funciones de señalización telefónica necesarias para la utilización del sistema de 4 ", /,//080,,. 3/0,5,79097, ,/02038, 08 5 " - 09 ;48/01:3. 43, ,,5.,. 3/0,70// 9, /0807; ,/48 6 " :3. 43, /0,5,790:8:,7 4/ ,!&% / ,/080,,. 3H 7 ", /,//01:3. 43,2 0394/0,80,,. 303,,5.,. 3,, , 26

27 señalización N. 7 en la señalización de control de llamadas telefónicas internacionales. Parte de control de Señalización (SCCP): Es un protocolo no orientado a conexión. Sin embargo, soporta servicios orientados a conexión. El SCCP permite que los mensajes sean utilizados por aplicaciones independientes dentro de cada nodo (subsistemas). Además, posee un sistema de enrutamiento avanzado que permite llevar un mensaje de un SSCP a otro sin necesidad de conocer la dirección del otro. Se encuentra regulada a través de la norma Q de la ITU-T, según la norma La parte control de la conexión de señalización (SCCP) proporciona funciones adicionales a la parte transferencia de mensajes (MTP) con objeto de prestar servicios de red con y sin conexión para transferir información de señalización relacionada con el circuito y no relacionada con el circuito, e información de otros tipos entre las centrales y centros especializados de las redes de telecomunicación, por una red del sistema de señalización N.º 7. [17] Parte de aplicación de capacidades de transacción (TCAP): Esta capa define los mensajes y protocolos utilizados para la comunicación entre las aplicaciones. TCAP proporciona funciones y protocolos a gran variedad de aplicaciones distribuidas entre centrales y centros especializados de las redes de telecomunicación (por ejemplo, bases de datos). Se encuentra normalizada bajo la norma Q de la ITU-T. El término "capacidades de transacción" se refiere a un conjunto de capacidades de comunicación que proporcionan interfaz entre las aplicaciones y un servicio de capa de red, es decir que TCAP permite la comunicación entre aplicaciones y las capas SCCP, MTP y cualquier capa del modelo OSI con características de capa de red. El objetivo fundamental de TCAP es proporcionar medios de 8 " :3. 43, /0,5, /0,.430 3/080,,. 3 27

28 transferencia de información entre nodos, así como suministrar servicios genéricos a aplicaciones, aunque manteniendo su independencia con respecto a ellas.[18] Direccionamiento en SS Nº. 7 En SS Nº. 7 el direccionamiento se realiza a partir del contenido del mensaje de señalización el cual varía de acuerdo a la capa y a la aplicación. Un mensaje de señalización es un conjunto de información, definido en el nivel 3 ó 4, relativo a una llamada, a una transacción de gestión, etc., que se envía como una entidad por la función de transferencia de mensaje. Cada mensaje contiene información de servicio, que identifica la parte de usuario de origen y probablemente información adicional, como sería una indicación de si el mensaje se refiere a una aplicación nacional o internacional de la parte de usuario. La información de señalización del mensaje incluye la información del usuario propiamente dicha, tal como una o más señales de control de la llamada de telefonía, de datos o RDSI, información de gestión y de mantenimiento, etc., e información identificativa del tipo y formato del mensaje. También incluye una etiqueta que proporciona información permitiendo que el mensaje sea: Encaminado por funciones del nivel 3 a través de la red de señalización hasta su destino. 9 " :3. 43, /0,8.,5,. /,/08/097,38,

29 Dirigido, en la parte de usuario receptora, a un determinado circuito, llamada, gestión u otra transacción con los que el mensaje esté relacionado. Existen cuatro tipos de etiquetas (Figura 5): Tipo A para mensajes de gestión MTP. Tipo B para mensajes TUP. Tipo C para mensajes PU-RDSI (relacionados con el circuito). Tipo D para mensajes SCCP. Figura 2. Tipos de Etiqueta de mensaje SS Nº. 7 A todos los puntos de señalización (SP, Signalling point) y a los puntos de transferencia de señalización (STP, Signalling transfer point) cuando estén integrados en un SP se les asigna un código de punto único y propio. La función de encaminamiento de la MTP utiliza éste para dirigir los mensajes salientes hacia su destino en la red, como indica la inclusión de un determinado código de punto apropiado incluido en la etiqueta de encaminamiento. Este código de punto se conoce como el código de punto de destino (DPC, destination point code). La etiqueta de encaminamiento también contiene el código de punto del SP que originó la unidad de señalización de mensaje, por lo tanto, la combinación de este 29

30 código punto de origen (OPC, originating point code) y del DPC determinará la relación de señalización (por ejemplo, los puntos de la red entre los cuales se intercambia la información de «usuario» de la MTP). El DPC es utilizado por la función de discriminación SP/STP receptora para determinar si el mensaje se dirige a ese SP o necesita ser encaminado más adelante mediante la capacidad de transferencia de señales del STP.[19] El DPC siempre se determinará e insertará en la etiqueta de encaminamiento por el «usuario» del MTP de nivel 4. Esto generalmente también será lo mismo para el OPC, pero es posible que, dado que el OPC es constante, pueda insertarse por la MTP. Figura 3. Mensajes SS7 En el nivel SCCP el enrutamiento se hace a partir de tres elementos distintos: el DPC, el titulo global (GT) y el numero de subsistema (SSN). Pueden estar presentes uno, dos o los tres elementos dentro de la dirección de la parte llamante o la parte llamada. 30

31 Figura 4. Capas de SS7 en Transacciones Descripción Parte de Aplicación Capacidad De Transacción (TCAP) Las capacidades de transacción (TC, transaction capabilities) proporcionan funciones y protocolos a gran variedad de aplicaciones distribuidas entre centrales y centros especializados de las redes de telecomunicación (por ejemplo, bases de datos) [13]. El término "capacidades de transacción" se refiere a un conjunto de capacidades de comunicación que proporcionan interfaz entre las aplicaciones y un servicio de capa de red. El objetivo general de las capacidades de transacción es proporcionar medios de transferencia de información entre nodos, así como suministrar servicios genéricos a aplicaciones, aunque manteniendo su independencia con respecto a ellas [13]. TCAP proporciona las características de la capa de aplicación (de acuerdo al modelo OSI) a un determinado nodo con servicios y protocolos para el diálogo con otro nodo equivalente. Dentro de una red de telefonía móvil TCAP permite proveer servicios genéricos para interactuar con diferentes tipos de inteligencia de red, siendo ésta independiente de las aplicaciones. Según la norma Q.771 de la ITU-T, TCAP puede ser utilizada entre: 31

32 Centrales Centrales y un centro de servicio de red. Centros de servicio de red Conceptos Básicos de TCAP Desde el punto de vista de un usuario final, las capacidades de transacción están situadas por encima de la capa de red del modelo OSI. Para suministrar servicios de capa de red a los usuarios finales se necesita la comunicación entre usuarios TCAP en diversos nodos de la red; estas comunicaciones intrarred pueden ser modeladas por medio del modelo de referencia de siete capas de OSI. TCAP se estructura en dos subcapas: La subcapa de componente, que trata de unidades de datos de protocolo de aplicación que transportan las operaciones a distancia y sus respuestas, con carácter facultativo, y el protocolo de la porción de diálogo para el transporte de información relativa al contexto de aplicación o de información de usuario.[13] La subcapa de transacción, que trata del intercambio entre dos usuarios TCAP de mensajes que contienen componentes y facultativamente una porción de diálogo.[13] 32

33 Figura 5. Capas de Aplicación TCAP Servicio proporcionado por la subcapa componente Componente Un componente es el medio por el cual la TCAP transporta una petición de realizar una operación o una respuesta. Una operación es una acción que debe llevar a cabo el extremo distante. Puede contener parámetros asociados. La invocación de una operación se identifica por un ID de invocación, esto permite que estén activas simultáneamente varias invocaciones de la misma operación o de operaciones diferentes. Sólo puede enviarse una respuesta a cada operación. La respuesta lleva una indicación de éxito o fracaso en la realización de la operación. Los componentes se pasan individualmente entre el usuario TCAP y la subcapa componente. El usuario TCAP de origen puede enviar varios componentes a la 33

34 subcapa componente antes de que sean transmitidos (en un solo mensaje) al extremo distante. En caso de que se reciban varios componentes dentro de un solo mensaje, se enviará cada uno individualmente al usuario TCAP de destino. Los componentes de un mensaje se envían al usuario TCAP distante en el mismo orden en que son entregados a la interfaz de origen. La importancia del orden se establece por un acuerdo previo entre los usuarios TCAP participantes.[13] Diálogo Un diálogo está constituido por el intercambio sucesivo de componentes entre dos usuarios TCAP con el fin de llevar a cabo una aplicación. La subcapa componente proporciona facilidades para el diálogo, permitiendo que varios diálogos se efectúen concurrentemente entre dos usuarios TCAP determinados [13]. El tratamiento por diálogo permite además, de un modo facultativo, la transferencia y negociación del contexto de aplicación, así como la transferencia transparente de información de usuario (es decir, datos que no son componentes) entre dos usuarios TCAP. Así mismo existen dos tipos de diálogos: los no estructurados y los diálogos estructurados Diálogo no estructurado Los usuarios TCAP pueden enviar componentes que no esperan respuestas, sin formar una asociación explícita entre ellos. Esto se denomina caso de diálogo no estructurado. La asociación implícita existe siempre entre los usuarios TCAP comunicantes. Ese diálogo no estructurado es soportado en el protocolo por el 34

35 mensaje unidireccional. Cuando un usuario TCAP envía un mensaje unidireccional a sus entidades pares indica el empleo de la facilidad de diálogo no estructurado. Cuando un usuario TCAP es receptor de un mensaje unidireccional y debe indicarse un error de protocolo, éste se devuelve también en un mensaje unidireccional Diálogo estructurado Otra solución es que los usuarios TCAP indiquen el inicio o la formación de un diálogo, su continuación y su final, lo cual se denomina diálogo estructurado. El empleo de diálogo estructurado permite que concurran varios diálogos entre dos usuarios TCAP, quedando identificado cada diálogo por un ID de diálogo particular. Cada ID de diálogo tiene un espacio de nombre ID de invocación distinto, por lo que pueden duplicarse ID de invocación en diálogos distintos. Puede proporcionarse la entrega de los mensajes en secuencia, mediante protocolos de aplicación fuera del alcance de la TCAP o empleando la clase de servicio SCCP apropiada. Cuando se utiliza el servicio de diálogo estructurado, el usuario TCAP tiene que indicar una de las cuatro posibilidades siguientes al enviar un componente a su entidad par: i) Inicio ii) Confirmación iii) Continuación iv) Terminación Facultativamente, en las fases i) y ii), es posible el intercambio de información sobre el contexto de aplicación y de información de usuario. Cuando se elige esta opción también puede enviarse información durante las fases iii) y iv). 35

36 Correlación de componentes La subcapa componente proporciona las siguientes facilidades: a) Asociación de operaciones y respuestas El valor del ID de invocación, que identifica sin ambigüedad una invocación de operación, se devuelve en una respuesta a dicha invocación de operación. Un usuario TCAP puede tener cierto número de operaciones activas en un momento determinado; el número máximo de aquéllas depende de las ID de invocación especiales que estén a disposición de dicho usuario en un momento cualquiera. Si la "respuesta" a esta invocación de operación es otra invocación de operación, desde el lado que responde se devuelve el ID de invocación original como un ID enlazado, indicando que esta invocación de operación de respuesta está "enlazada" a la operación original. Se consideran cuatro clases de operaciones: Clase 1, Se informa tanto del éxito como del fracaso. Clase 2, Se informa sólo del fracaso. Clase 3, Se informa sólo del éxito. Clase 4, No se informa ni del éxito ni del fracaso. En caso necesario, el usuario TCAP realiza la segmentación de una respuesta de éxito. Además, se puede enviar cualquier número de operaciones enlazadas antes de la respuesta. La respuesta puede ser: 36

37 Un retorno de resultado que indica éxito. Un retorno de error que indica fracaso de operación. Un rechazo que indica incapacidad para realizar la operación. El que elabora el protocolo de aplicación decide lo que constituye éxito o fracaso en la ejecución de la operación. Se puede rechazar cualquier componente, con la excepción del componente de rechazo. El rechazo de un resultado produce la terminación de la operación correspondiente; el rechazo de una operación enlazada no afecta a la operación con la que ésta se enlaza. El rechazo de un segmento de un resultado (es decir, rechazo de un retorno de resultado no el último componente) implica el rechazo de todos los segmentos subsiguientes y también de todo el resultado. Un usuario TCAP puede cancelar una operación que haya invocado previamente. Cualquier respuesta a esta invocación que se reciba posteriormente será rechazada. b) Tratamiento de situaciones anormales La subcapa componente trata diversas situaciones anormales en relación con un componente: Rechazo de componente: Informa al usuario o usuarios TCAP en caso de que la subcapa componente reciba un componente incorrectamente formado o un componente que viole las reglas de intercambio de operaciones y respuestas. 37

38 Expiración del tiempo para una operación: Cuando la subcapa componente detecta que una operación de clase 1, 2 ó 3 no ha recibido una respuesta final tras cierto tiempo (que está especificado por la aplicación y depende de la operación), libera el correspondiente ID de invocación e informa al usuario TCAP. Obsérvese que esta situación es anormal únicamente en el caso de operaciones de clase 1. La aplicación de esta situación a operaciones de clase 4 es un asunto local. Cancelación de invocación: Un usuario TCAP puede decidir liberar un determinado ID de invocación y hacer caso omiso de cualquier respuesta que utilice este identificador Tratamiento de errores Cuando la subcapa componente es informada de una situación que le impide proporcionar el servicio esperado por los usuarios TCAP, notificará al usuario TCAP y podrá terminar las operaciones pendientes. Un usuario TCAP puede decidir abortar un diálogo, lo que pone fin a cualquier operación pendiente Servicio proporcionado por la subcapa transacción La subcapa transacción (TR, transaction) proporciona la capacidad de intercambio de componentes y, con carácter facultativo, una porción de diálogo entre usuarios TR. La subcapa transacción proporciona también la capacidad de envío de mensajes de transacción entre entidades de capa TR pares mediante los servicios proporcionados por los servicios de red de capa inferior. El único usuario TR 38

39 previsto por el momento es la subcapa componente. Se prevén dos tipos de servicio Diálogo no estructurado No hay iniciación explícita ni terminación en un diálogo no estructurado. La única facilidad proporcionada al usuario TCAP es la capacidad de enviar uno o varios componentes que no esperan respuesta (invocación de operaciones de la clase 4), agrupados en un mensaje unidireccional, al usuario TR distante. En el lado de origen, el usuario TCAP indica los componentes que han de enviarse en un mensaje unidireccional mediante primitivas del tipo petición, que contienen un ID de diálogo único. Cuando el usuario TCAP envía una primitiva de petición TC-UNI con el mismo ID de diálogo, todos los componentes con el mismo ID de diálogo son enviados por la subcapa componente, como datos de usuario, a la subcapa transacción mediante la primitiva TR-UNI. En el nivel de mensaje de subcapa transacción, el mensaje unidireccional no contiene ningún ID de transacción, por lo que no establece ninguna asociación entre los mensajes de este tipo. El ID de diálogo se emplea para enviar a una dirección de destino concreta un grupo de componentes en un mensaje unidireccional (UNI, unidirectional) Diálogo estructurado La facilidad de diálogo estructurado permite que un usuario TCAP inicie un diálogo, intercambie componentes en ese diálogo, lo termine o lo aborte. Cada usuario TR identifica una transacción por medio de un ID de transacción distinto. Con este tipo de diálogo se proporcionan las siguientes facilidades: 39

40 Comienzo de transacción: El comienzo de una transacción entre dos usuarios TR causa la asignación de un ID para esta transacción y permite el envío de información de usuario TR al usuario TR de destino. Como reacción a un comienzo de transacción, el usuario TR de destino puede continuar la transacción o finalizarla. Continuación de transacción: Permite el intercambio de mensajes en modo dúplex entre usuarios TR dentro de una transacción. Finalización de transacción: Libera el ID de transacción asociado y pone fin al intercambio de mensajes dentro de esta transacción. Cualquiera de los usuarios TR puede decidir la finalización de una transacción. Para el usuario TR hay tres formas de terminar una transacción: Finalización preconvenida: Existe un convenio entre los usuarios TR, cada uno de ellos puede decidir la terminación de la transacción sin tener que informar al otro usuario TR, el cual tomará por sí mismo una decisión similar. Finalización básica: Informa al usuario TR par posiblemente enviándole información de usuario TR. Aborto de transacción: Deja de enviar cualquier mensaje de la transacción que esté pendiente de transmisión o entrega, y finaliza la transacción. Se indica al usuario TR distante el motivo del aborto de la transacción. 40

41 Si, por cualquier motivo, no se recibe respuesta alguna al comienzo de la transacción, la subcapa transacción abortará finalmente esta transacción e informará al usuario TR. Aborto de transacción por la TCAP: Siempre que se detecte una situación anormal, la subcapa transacción decidirá abortar la correspondiente transacción e informará a los usuarios TR. Informe de situación de excepción: La subcapa transacción puede informar a los usuarios TR acerca de situaciones anormales de las que sea notificada por la capa subyacente. Cuando el usuario TR es la subcapa componente existe una correspondencia biunívoca entre un diálogo y una transacción. Un mensaje puede contener cero, uno o más componentes, dentro de los límites del tamaño de mensaje admitido por la capa de red subyacente Servicio proporcionado por TC basadas en un servicio de red sin conexión Primitivas de la Subcapa de componente La finalidad de estas primitivas es la petición o la indicación de facilidades de la (sub)capa subyacente, en relación con la transmisión de mensajes o el tratamiento del diálogo. Cuando se utiliza la subcapa transacción para soportar el diálogo, estas primitivas se corresponden con primitivas TR con el mismo nombre genérico, ya que existe una relación biunívoca entre un diálogo y una transacción. 41

42 En la Tabla 1 se muestra el listado de las primitivas utilizadas en la subcapa de componente, cada una de estas primitivas corresponde a una función dentro del diálogo. Las Primitivas que se describe a continuación causa el envío, al extremo distante, de todo componente o componentes previamente enviados a la interfaz para el diálogo en cuestión (excepto TC-FINALIZACIÓN con finalización preconvenida). Si tales primitivas contienen información relativa al tratamiento de diálogo, se forma una porción de diálogo y se envía ésta concatenada con el componente o la secuencia de componentes. TC-UNI: Pide / indica un diálogo no estructurado. TC-COMIENZO: Empieza un diálogo. TC-CONTINUACIÓN: Continúa un diálogo. TC-FINALIZACIÓN: Finaliza un diálogo. Nombre TC-UNI TC-COMIENZO (TC-BEGIN) TC-CONTINUACIÓN (TC-CONTINUE) TC-FINALIZACIÓN (TC-END) TC-U-ABORTO (TC-U-ABORT) TC-P-ABORTO (TC-P-ABORT) TC-NOTIFICACIÓN (TC-NOTICE) Tipo Petición Indicación Petición Indicación Petición Indicación Petición Indicación Petición Indicación Indicación Indicación Tabla 1. Primitivas para el tratamiento de diálogo 42

43 En caso de presentarse algún inconveniente para dar un correcto procesamiento a la transacción se utilizan las siguientes primitivas: TC-U-ABORTO: Permite a un usuario TC terminar brúscamente un diálogo sin transmitir ningún componente que esté pendiente. TC-P-ABORTO: Informa al usuario TC de que el diálogo ha sido terminado por el proveedor del servicio (es decir, la subcapa TC transacción) como reacción al aborto de una transacción por la subcapa transacción. No se transmite ningún componente que esté pendiente. TC-NOTIFICACIÓN: Informa al usuario TC que el proveedor de servicio de red ha sido incapaz de proporcionar el servicio pedido. Para el tratamiento de componentes se utilizan otro grupo de primitivas; la función principal de estas primitivas es el tratamiento de operaciones y respuestas. A continuación se muestra la descripción de cada una de estas primitivas y en la tabla 2 se resumen: TC-INVOCACIÓN: Invocación de una operación, que puede estar enlazada a otra invocación de operación. TC-RESULTADO-L: Resultado único o última parte del resultado segmentado de una operación ejecutada con éxito. TC-RESULTADO-NL: Parte no final del resultado segmentado de una operación ejecutada con éxito. TC-U-ERROR: Respuesta a una operación invocada previamente, indicando que ha fallado la ejecución de la operación. 43

44 TC-L-CANCELACIÓN: Informa localmente al usuario TC de que se ha terminado una invocación de operación a causa de una condición de expiración de temporización. TC-U-CANCELACIÓN: Causa la terminación local de una invocación de operación, como consecuencia de una decisión del usuario TC. TC-L-RECHAZO (rechazo local): Informa al usuario TC local de que se ha recibido un componente no válido detectado por la subcapa componente. TC-R-RECHAZO (rechazo distante): Informa al usuario TC de que ha sido rechazado un componente por la subcapa componente distante. TC-U-RECHAZO: Rechazo de un componente por el usuario TC, que indica una malformación que impide ejecutar una operación o comprender una respuesta. TC-REINICIACIÓN-TEMPORIZADOR: Permite al usuario TC local actualizar un temporizador de una invocación. Nombre TC-INVOCACIÓN (TC-INVOKE) TC-RESULTADO-L (TC-RESULT-L) TC-RESULTADO-NL (TC-RESULT-NL) TC-U-ERROR TC-L-CANCELACIÓN (TC-L-CANCEL) Tipo Petición Indicación Petición Indicación Petición Indicación Petición Indicación Indicación 44

45 TC-U-CANCELACIÓN (TC-U-CANCEL) TC-L-RECHAZO (TC-L-REJECT) TC-R-RECHAZO (TC-R-REJECT) TC-U-RECHAZO (TC-U-REJECT) TC-REINICIACIÓN-TEMPORIZADOR (TC-TIMER-RESET) Petición Indicación Indicación Petición Indicación Indicación Tabla 2. Primitivas para el tratamiento de componentes Manejo del Diálogo Estructurado La facilidad de diálogo estructurado permite a un usuario TC empezar un diálogo, facultativamente intercambiar información sobre el contexto de aplicación y el usuario intercambiar componentes dentro del diálogo, terminarlo o abortarlo. Un usuario TC inicia un nuevo diálogo enviando una primitiva de petición TC- COMIENZO. La finalidad de esta primitiva es: Indicar a la subcapa componente que empieza un nuevo diálogo, identificado por el parámetro "ID de diálogo" de la primitiva. Solicitar la transmisión de cualquier componente o componentes pasados previamente a la subcapa componente por medio de primitivas de tratamiento de componente del tipo "petición" con el mismo ID de diálogo. El usuario TC que inicia un nuevo diálogo puede indicar también, de un modo facultativo, el nombre del contexto de aplicación que le es aplicable. Se puede enviar una primitiva de petición TC-COMIENZO antes de pasar cualquier 45

46 componente a la subcapa componente. En el lado receptor se informa al usuario TC de destino acerca del comienzo de un nuevo diálogo por medio de una primitiva indicación TC-COMIENZO. La presencia de uno o varios componentes viene indicada por el parámetro "componentes presentes". Parámetro Primitiva: TC-COMIENZO Petición Indicación Calidad de servicio U O (nota 2) Dirección de destino M M (nota 1) Nombre del contrato de aplicación U C (=) Dirección de origen M (nota 1) M (=) ID de diálogo M M Información de usuario U (nota 3) C (=) Componentes presentes M NOTA 1 Este parámetro puede asociarse implícitamente con el punto de acceso en que se genera la primitiva. NOTA 2 Cuando esta información la facilita la capa subyacente debe pasarse también al usuario del servicio. NOTA 3 La información de usuario únicamente puede incluirse si se incluye también el parámetro nombre del contexto de aplicación. Tabla 3. Primitivas TC-COMIENZO Un usuario TC indica que desea continuar un diálogo emitiendo una primitiva de petición TC-CONTINUACIÓN. Esta primitiva establece el diálogo propuesto en la primitiva de indicación TC-COMIENZO recibida. En esta etapa, el usuario TC puede incluir opcionalmente una dirección de origen. Este parámetro opcional sólo se aplica a la primera continuación hacia atrás (es decir, al establecimiento del diálogo), una vez establecido un diálogo las direcciones no cambian. Si el nombre del contexto de aplicación en la primitiva de indicación TC- COMIENZO es aceptable, el usuario TC incluye el mismo valor en la primera primitiva de petición hacia atrás TC-CONTINUACIÓN. El usuario TC puede indicar 46

47 también que desea continuar un diálogo con otro contexto de aplicación que no sea el propuesto por el iniciador del diálogo. La primitiva petición TC-CONTINUACIÓN solicita la transmisión de cualquier componente o componentes que hayan sido pasados a la subcapa componente para este diálogo, desde que la primitiva indicación TC-COMIENZO fue recibida para este diálogo. En el lado receptor, la primitiva indicación TC-CONTINUACIÓN señala: Que el diálogo puede continuar. En el caso de que la porción de diálogo fuera utilizada al comienzo del diálogo, el contexto de aplicación que regirá para el resto del diálogo. Que se entregan componentes (si el parámetro "componentes presentes" no indica "nulo"). Parámetro Primitiva: TC-CONTINUACIÓN Petición Indicación Calidad de servicio U O (nota 1) Dirección de origen O (nota 2) Nombre del contexto de aplicación U C (=) ID de diálogo M M Información de usuario U (nota 3) C (=) Componentes presentes NOTA 1 Cuando esta información la facilita la capa subyacente, ha de pasarse también al usuario del servicio. NOTA 2 Este parámetro no se pasa al usuario TC. NOTA 3 La información de usuario únicamente puede incluirse si se incluye también el parámetro nombre del contexto de aplicación. M Tabla 4. Primitivas TC-CONTINUACIÓN 47

48 La finalización normal de un diálogo (los dos primeros escenarios) utiliza las primitivas de petición e indicación TC-FINALIZACIÓN que se describen en la tabla 5. El parámetro "terminación" de la primitiva de petición TC-FINALIZACIÓN indica el escenario que se va a utilizar para terminar el diálogo. Los tipos de finalización son los siguientes: Finalización preconvenida: En este escenario, los usuarios TC han convenido con anterioridad cuándo terminar el diálogo. El efecto de la primitiva de petición TC-FINALIZACIÓN es totalmente local, no se utiliza indicación TC-FINALIZACIÓN. No se puede enviar ni recibir ningún componente para el diálogo una vez emitida la primitiva de petición TC- FINALIZACIÓN. Finalización básica: En este escenario, la finalización causa la transmisión de cualquier componente que esté pendiente en el lado que la inicia. Sin embargo, debe tenerse en cuenta que no se entregarán los componentes que estén pendientes de transmisión en el sentido opuesto. Aborto de un diálogo por un usuario TC: El usuario TC tiene la facultad de solicitar la finalización inmediata de un diálogo sin tener en cuenta ninguna invocación de operación pendiente (aborto). Una petición de aborto del usuario TC hace que se terminen todas las operaciones pendientes para ese diálogo. Cuando haga esto, el usuario TC puede proporcionar información de extremo a extremo que indique la causa del aborto, así como información de diagnóstico, la TCAP transporta esta información sin análisis. Antes de que se haya establecido el diálogo (esto es, antes de la primera TC-CONTINUACIÓN), el usuario TC puede decidir también abortar el diálogo porque no pueda admitirse el nombre del contexto de aplicación propuesto por el iniciador del diálogo. En este caso el aborto puede indicar 48

49 un nombre de contexto de aplicación alternativo susceptible de ser utilizado por el iniciador del diálogo para abrir otro diálogo con la misma finalidad. Parámetro Primitiva: TC-FINALIZACIÓN Petición Indicación Calidad de servicio U O (nota 1) ID de diálogo M M Nombre del contexto de aplicación U (nota 2) C (=) Componentes presentes Información de usuario U (nota 3) C (=) Terminación NOTA 1 Cuando esta información la facilita la capa subyacente, ha de pasarse también al usuario del servicio. NOTA 2 Estos parámetros facultativos se permiten únicamente para el caso en que la petición TC-FINALIZACIÓN se envía como respuesta inmediata a una indicación TC-COMIENZO recibida. NOTA 3 La información de usuario puede incluirse únicamente si se incluye también el parámetro nombre del contexto de aplicación o si éste ha sido utilizado en el establecimiento del diálogo. M M Tabla 5. Primitivas TC-FINALIZACIÓN Si el servicio solicitado no puede ser prestado se pasa al usuario a través de una uprimitiva de indicación TC-NOTIFICACIÓN. Parámetro ID de diálogo Dirección de origen Dirección de destino Causa de informe Primitiva: TC-NOTIFICACIÓN Indicación O O O M Tabla 6. Primitivas TC-NOTIFICACIÓN 49

50 OPERACIONES Las operaciones efectuadas por los usuarios TCAP se efectúan y controlan a través de primitivas y éstas se clasifican en INVOKE y REQUEST, de acuerdo al origen. Se solicita una invocación de operación a la subcapa componente, por medio de una primitiva de petición TC-INVOCACIÓN. Cuando esta invocación está enlazada a una operación previa, se utiliza el parámetro ID enlazado. La primitiva de indicación TC-INVOCACIÓN se usa para indicar la activación de la operación al usuario TC de destino. Parámetro Primitiva: TC-INVOCACIÓN Petición Indicación ID de diálogo M M (nota) Clase M ID de invocación M M (=) ID enlazado U C (=) Operación M M (=) Parámetros U C (=) Ultimo componente M Temporización M NOTA Obligatorio, salvo para la invocación de operación de clase 4 recibida en un mensaje unidireccional. Tabla 7. Primitivas TC-INVOCACIÓN La respuesta de una operación se puede ver como la información del éxito la cual se informa a través de las siguientes primitivas: TC-RESULTADO-L: Indica el único o último segmento de un resultado. 50

51 TC-RESULTADO-NL: Indica un segmento de un resultado (al que seguirán más segmentos). TC no impone limitación alguna en cuanto al número de segmentos. No obstante, cuando los usuarios TC pares están seguros de que el servicio de red sustenta la segmentación y reensamblado de los datos de usuario, la facilidad TC-RESULTADO-NL (RR-NL) no es necesaria y deberá ser evitada. Parámetro Petición TC-RESULTADO-L TC-RESULTADO-NL Primitiva Indicación TC-RESULTADO-L TC-RESULTADO-NL ID de diálogo M M ID de invocación M M (=) Operación U (nota) C (=) Parámetros U C (=) Ultimo componente M Tabla 8. Primitivas TC-RESULTADO La transacción se puede rechazar en un momento dado. Para esto se utiliza la primitiva TC-U-RECHAZO la cual es una primitiva de petición. En la tabla 9 se muestra la estructura de esta primitiva. Parámetro Primitiva: TC-U-RECHAZO Petición Indicación ID de diálogo M M (nota) ID de invocación M M (=) Código de problema M M (=) Último componente M Tabla 9. Primitivas TC-U-RECHAZO 51

52 2 PLANTEAMIENTO DEL PROBLEMA Y EVOLUCION DEL PROYECTO El objetivo fundamental de este trabajo fue diseñar un punto de control de servicios dentro de una red de señalización existente y proponer un plan de implementación dentro de la misma, basándonos en el modelo del protocolo SS7 y utilizando las capacidades de transacción del mismo con el fin de crear un diálogo entre una central de conmutación y un elemento de red externo, en nuestro caso un servidor de base de datos. Para cumplir con este objetivo se diseñaron dos elementos independientes: el módulo SCP y el módulo de base de datos. El módulo SCP se implementó bajo el entorno de programación Visual Studio 6. Para la decodificación de parámetros se incluyeron archivos tipo INI de configuración, librerías para manejo del registro de Windows NT y librerías y clases para el manejo de base de datos (Librerías ODBC). Adicionalmente, posee una tarjeta de señalización Datakinetics PCCS3 con el Stack MTP (niveles 1,2 y3) y SCCP. Para el manejo de la mensajería entre la tarjeta de señalización y el programa de control se utilizó la librería de manejo proporcionado por el fabricante de la tarjeta. Para la construcción del módulo de base de datos se utilizó el motor SYBASE ASE y los drivers nativos del mismo. Se utiliza el lenguaje de consulta estructurado (SQL) para realizar las operaciones de modificación, adición, borrado o creación de ítems en las diferentes tablas de la base de datos y modificación de los procedimientos almacenados. 52

53 La unión de los dos módulos se realiza utilizando las librerías de base de datos y utilizando conexiones orientadas (ODBC). 2.1 Consideraciones Iniciales Módulo SCP Para tener acceso a los mensajes de TCAP y de IS-41 provenientes de la red de señalización es necesario ser parte de la red para esto se debe configurar un punto de código dentro de la red (punto de señalización). Como paso siguiente se debe tener el stack MTP con sus tres niveles para poder tener acceso a la conexión física, tener capacidad de enrutamiento y mantener la comunicación todo el tiempo. De la misma forma se debe contar con el Stack de SCCP para poder descomponer los mensajes. Por último, estos mensajes deben ser decodificados por la capa propietaria de los mismos: en nuestro caso se trata de TCAP y de IS41. Para poder cumplir con esas tareas el módulo tiene que contar con un sistema robusto que pueda realizar la decodificación en forma rápida y eficiente, por lo cual el entorno en el que se diseñe debe contar con las siguientes características: robustez, escalabilidad, flexibilidad y estabilidad. Se debe contar con un equipo capaz de manejar las capas MTP y SCCP. Debido a que el módulo SCP está todo el tiempo conectado a la red de señalización como un elemento de red más, se consideró independizar la parte de análisis y aplicaciones. 53

54 2.1.2 Módulo de Base de Datos Para el procesamiento de los datos contenidos dentro de cada uno de los mensajes es necesario contar con un ambiente de base de datos muy robusto, que permita crear funciones propias, con rutinas de mantenimiento definidas y, sobre todo, que posea una alta disponibilidad. El motor de base de datos debe permitir la programación de tareas, la generación de disparos ante eventos o datos específicos; con esto se le otorga mucha independencia del módulo SCP, ya que el motor de base de datos puede ser programado, de acuerdo al criterio del administrador, para que responda en una forma especifica para una transacción determinada. Otro requisito para el módulo de base de datos es que soporte múltiples sesiones, que maneje esquemas de redundancia y verificación de la consistencia de los datos. El motor de bases elegido es el Sybase Adaptive Enterprise que cumple con todas nuestras especificaciones, se instalará la aplicación sobre el sistema operativo Linux, con el fin de proporcionarle la estabilidad necesaria y acceso a esquemas de redundancia como espejos de discos o servidores de backups satelitales. Adicionalmente, Sybase permite la programación de disparos en tiempo real, el copiado de datos por volumen, la programación de rutinas de análisis y manejo de datos especiales, el envío de comandos hacia servidores Linux/Unix y el manejo dinámico e independiente de memoria y disco duro. 54

55 2.2 METODOLOGÍA INICIAL Módulo SCP Como punto de partida para el desarrollo de este sistema se recurrió al estudio de la conexión física con la red de señalización con ayuda de una interfaz de hardware que proporcionará las características físicas y lógicas necesarias. La elección de esta interfaz estuvo ligada a la necesidad de intercambiar información entre un sistema de cómputo y la red de señalización. Después de la investigación se encontró una interfaz que cumplía con estas características y que estaba en capacidad no solo de proporcionarnos conexión física sino de manejar las 3 capas de MTP y de interpretar la mensajería SCCP a través de librerías de programación incluidas. El siguiente paso fue elegir las librerías que más se adaptaran a las necesidades del sistema y estudiar a fondo las características propias de la interfaz. Para esto se tuvo en cuenta que era necesario integrar estas librerías al entorno de programación Visual Studio, el fabricante de las interfaces a través de su portal de Internet [24] nos suministró información necesaria. Dentro de los planteamientos iniciales se tenía la idea de hacer un sistema totalmente distribuido, por lo cual se había pensado instalar la tarjeta en un computador personal con sistema operativo Linux, pero la tarjeta no respondió de acuerdo a lo esperado. Se consultó al fabricante llegando a la conclusión de utilizar Windows NT, como el sistema operativo bajo el cual funcionaría el módulo SCP. Una vez escogidas las librerías y el ambiente de trabajo se inicia el proceso de implementación encontrando con éste algunas características no documentadas de las mismas, referentes a los tiempos de respuesta y a los buffers necesarios para el cumplimiento de sus funciones básicas. Adicionalmente a esto las librerías no podían ser programadas dentro de un bloque único de software sino que 55

56 debían ser llamadas a través de hilos de programación, ya que cada una de sus funciones realiza una labor especifica dentro del stack de protocolo que maneja. Todos estos impases obligaron a cambiar los planteamientos iniciales y a la creación de librerías propias que hacían llamados a las funciones incluidas dentro de las librerías del fabricante. Ya superada la configuración de la interfaz se verificó la elección del entorno de programación y sus aportes a las características necesarias dentro del módulo SCP. Con toda la carga transaccional de este módulo se decidió no implementar el sistema de operación y mantenimiento dentro de él sino como un sistema aparte, con el fin de no consumir recursos de máquina. Con todos estos ajustes se pudo llegar a un replanteamiento de la metodología inicial, que trajo consigo un método definitivo que desarrolla el sistema Módulo de Base de Datos La metodología utilizada para la construcción del módulo de Base de Datos, consistió en un planteamiento teórico de las características del mismo, utilizando un diagrama de entidad relación. Una vez obtenido el resultado, se procedió a verificar si el motor de base de datos elegido en los planteamientos iniciales cumplía con estas características. El siguiente paso consistió en simular todas las posibles transacciones que recibiría el módulo con sus tiempos de respuesta, con el fin de obtener los diagramas de flujo de cada uno de los procedimientos a utilizar dentro del módulo. 56

57 El estudio de SQL llevo a la simplificación de los diagramas de flujo y el estudio de las características de Sybase como motor de base de datos nos llevó a un modelo teórico lo bastante completo para servir de apoyo al módulo SCP. El principal inconveniente que se presentó en el diseño de módulo estuvo en la consecución del driver ODBC para conectar el módulo SCP a nuestro módulo de Base de Datos, por lo que se procedió a investigar sobre la creación de un driver nativo. Para esto se utilizaron las librerías de conexión a base de datos de distribución gratitua para el entorno de programación Visual C 6.0. Una vez elegidas las herramientas a utilizar y tomando en cuenta las dificultades iniciales encontradas se procedió a realizar modificaciones a la metodología para realizar el método definitivo que desarrollara finalmente el sistema. 2.3 METODO DEFINITIVO Módulo SCP A partir de las consideraciones y la metodología inicial el método definitivo es el desarrollo de un programa divido en submódulos; cada uno de ellos se encuentra implementado como una tarea independiente dentro del módulo principal, configurable a partir de archivos de inicialización propietarios de Windows NT y del registro de Windows. En la primera parte de la metodología se trabaja sobre la interfaz de conexión con la red de señalización, encontrando el proveedor y el equipo que cumple con esas características. Una vez se posee la información de conectividad de la interfaz con el entorno de programación Visual C 6.0, se procede a la incorporación de las librerías para el control de la interfaz. 57

58 Se realiza el análisis de las funciones incluidas dentro de la interfaz para el manejo de las capas MTP y SCCP, una vez estudiadas se realizan los diagramas de flujo de cada una de las rutinas del programa principal y los submódulos complementarios para el cumplimiento de los objetivos del sistema teniendo en cuenta las recomendaciones de la ITU-T [12] [14]. Una vez completada la parte de MTP y SCCP se procede a diseñar los filtros e interpretes de TCAP y de IS-41. Para esto nos remitimos a la información de la ITU-T [13], con el fin de obtener un listado de los mensajes y códigos de error que aplicarán para nuestro proyecto. Teniendo esto pasamos a la parte de diseño de diagramas de flujo que cumplan con cada una de las tareas necesarias. Se realiza un estudio de la mensajería propietaria de Ericsson para el intercambio transaccional y de las configuraciones de central necesarias para poder comunicarse con un SCP. Una vez completos los diagramas de flujo totales del sistema se inicia la construcción de los algoritmos utilizando para esto el entorno de programación Visual Studio 6.0, se crean librerías de decodificación para cada uno de los componentes de TCAP y de IS-41. Dentro de la metodología se desarrolla un módulo de pruebas, que captura los mensajes de una capa específica y permite la decodificación manual. Con esto se quiere verificar cómo están siendo recibidos los mensajes. Escogemos un punto de señalización para ser cargado dentro de la configuración inicial del módulo con el fin de conectar el módulo dentro de la red de señalización. Este punto de señalización es programado dentro de la central Ericsson como una central cooperante en la parte de IS

59 Se desarrolla un programa de depuración de errores, el cual simula mensajes de TCAP inválidos, para verificar la interpretación de los códigos de error contenidos dentro del protocolo. Se diseña el ambiente de pruebas final del módulo SCP, basándose en el modelo conceptual de redes inteligentes normalizado por la TIA/EIA-664. En esta parte se llegó a la necesidad de modelar el sistema basándonos en esta recomendación ya que permitió ver claramente cada uno de los procedimientos, funciones, librerías y submódulos como pequeños sistemas con funciones definidas dentro del módulo SCP. La interfaz de usuario se desarrolló basándose en el conocimiento de que sobre este módulo deben realizarse labores de operación y mantenimiento frecuentes, por lo cual se trabajó básicamente con las librerías de Visual Studio para el manejo gráfico. La conexión con el módulo de base de datos se realizó utilizando un driver nativo que fue desarrollado en Visual Studio. Finalmente se desarrolló un módulo de operación y mantenimiento que se encargue de verificar la generación de reportes de estado y el monitoreo de la integridad de las transacciones. El cliente para manejar los servicios y bases de datos se diseñó con la herramienta SQL designer de Sybase, que poseía una gran cantidad de funciones de mucha utilidad para nuestro proyecto. 59

60 2.3.2 Módulo de Base de Datos El módulo base de datos se diseñó a partir de las necesidades de un modelo entidad relación, donde se especifican las entradas y salidas de cada una de las consultas, las funciones de queden cumplir los procedimientos almacenados, el diseño de disparos, los tipos de datos y las relaciones entre tablas. Fue necesaria la creación de un protocolo de comunicación con el módulo SCP con el fin de estandarizar la comunicación y limitar los mensajes de Error y los campos admitidos. Esto permitió delimitar las funciones propias del proyecto. Se realizó un estudio de las características funcionales del motor de base de datos con fin de aprovechar al máximo las ventajas; entre ellas se diseño un script en Linux que trabaja como un intérprete para las labores de operación y mantenimiento. Se creó un cliente para realizar cambios en las funciones de la base de datos; para esto se utiliza el entorno de programación Borland Delphi, el cual a su vez permite realizar consultas. Finalmente se realizan las pruebas de comunicación con el módulo SCP. 2.4 LOGROS ADICIONALES Para las pruebas del sistema se implementó un modelo de red inteligente basándonos en la recomendación TIA/EIA-664. Para esto todo el sistema se estructuró en bloques funcionales y se integró a la red de señalización como subsistemas de tareas específicas. Se realizó un plan de implementación dentro de la red de señalización nacional, realizando un análisis del estado actual y estado futuro descrito en el anexo A. 60

61 A partir de la interpretación y decodificación inicial de los mensajes se pasó a implementar dentro de los algoritmos los cambios de parámetros propios de la modificación de los estándares por parte de los fabricantes. Para permitir la comunicación entre nuestro SCP y la central de conmutación fue necesario realizar la configuración de parámetros en la central Ericsson. Esta configuración se presenta en el Anexo C. 61

62 3 DESARROLLOS E IMPLEMENTACIONES El desarrollo de este proyecto se realizó agrupando las funciones básicas en dos grandes módulos: el primero de ellos desarrollado en Visual C++ que maneja toda la parte de señalización y el otro utiliza un motor de base de datos Sybase Adaptive Server Enterprise para analizar y entregar respuesta a los requerimientos enviados desde la parte de señalización. La figura 6 muestra el diagrama en bloques del sistema. Figura 6. Diagrama en Bloques del Sistema 62

63 Las funciones de cada módulo son descritas en este capitulo. Las funciones principales de los distintos módulos se describen mediante diagramas de flujo en los Anexos D, E, F, H, I, J, K, L y Q. 3.1 Módulo de SCP Subsistema MTP El subsistema MTP esta basado en las recomendaciones Q.701 a la Q.707 del organismo de estandarización ITU-T. La función principal del subsistema MTP es la de servir como un sistema de transporte, proporcionando una transferencia confiable de cada uno de los mensajes de señalización entre la red de señalización y los subsistemas complementarios. Mediante el subsistema MTP se define un nodo dentro de la red de señalización. Este nodo se define como un punto extremo de señalización (SEP). El punto de señalización escogido fue el en formato nacional; en los mensajes esta dirección viaja en el encabezamiento MTP como se muestra en la figura 7. Figura 7. Encabezamiento MTP Los mensajes que viajan en desde nuestro SCP hacia la red de señalización tienen los siguientes valores: OPC = DPC =

64 El subsistema MTP verifica el destino de los mensajes, decodificando el Service Indicator Octect (SIO) y enrutando a la capa correspondiente el mensaje, en nuestra implementación, cualquier mensaje que vaya con un destino diferente al SCCP es rechazado, por el subsistema MTP. Figura 8. Distribución de mensajes La implementación del subsistema MTP se realizó a través de la tarjeta PCCS3 de Datakinetics. Para la comunicación con los otros usuarios MTP se utilizan las Primitivas MTP-PAUSE, MTP-RESUME, MTP-STATUS a través de 3 funciones desarrolladas en visual C++ e incorporadas a manera de Clases dentro del módulo SCP. Estos procedimientos son ProcessMtpMsgResume, ProcessMtpMsgPause y ProcessMgtMsgMtpEvent, los cuales se encargan de capturar la información propia del enlace, decodificarla e indicarle al sistema el estado del mismo. En el anexo B se encuentra el algoritmo diseñado. La 64

65 información sobre los parámetros propios de la tarjeta y sus mensajes para la parte de MTP son descritos en el Anexo H. El subsistema MTP envía información de los siguientes eventos para el control del subsistema de mantenimiento: Errores en el enlace de señalización. Congestión hacia el nivel 3 (MTP Nivel 3,Network). Detección de fallas en el enlace de señalización. La configuración de todos los parámetros del subsistema es realizada a través de un archivo llamado config.txt, cuya estructura se encuentra descrita en el manual de configuración (Anexo I). En la figura 9 se muestra el archivo config.txt. 65

66 Figura 9. Parámetros MTP Archivo Config.txt El programa permite ver todos los links configurados y su estado actual gracias al subsistema de MTP. La figura 10 muestra la ubicación de la información suministrada por el subsistema MTP a la interfaz de usuario. 66

67 Figura 10. Subsistema MTP dentro de la Interfaz de Usuario Las respuestas a las transacciones son recibidas desde el subsistema SCCP a través del mensaje SCP_MSG_TX_REQ (Ver Anexo M). Una vez recibidas son transmitidas hacia la red de señalización colocando la información de MTP correspondiente Subsistema SCCP El subsistema SCCP está implementado a través de la tarjeta PCCS3 de Datakinetics para la parte de comunicación con la capa MTP3, y se desarrolló un algoritmo para el control y decodificación de los mensajes desde y hacia la capa de transacciones, al igual que para el monitoreo de estado de cada uno de los subsistemas como se describirá mas adelante. Este subsistema fue implementado siguiendo las recomendaciones Q.711 a la Q-714 de la ITU-T. 67

68 Para tener comunicación con MTP utilizamos un grupo de primitivas que se detallan a continuación: MTP-TRANSFER-REQ: Solicitud de transmisión a MTP. MTP-TRANSFER-IND: Indicador de Recepción desde MTP. MTP-PAUSE: Punto de Señalización no disponible. MTP-RESUME: Disponibilidad de Punto de Señalización. MTP-STATUS: No disponibilidad de la parte de MTP. En el anexo I se especifican cada uno de los formatos de los mensajes utilizados para la comunicación de los módulos y que se convierten en las variables de entrada y salida del subsistema SCCP. Se inicia con una rutina de inicialización a través del procedimiento denominado SCCPConfig, el cual recibe los siguientes parámetros: Módulo: En este campo se detalla la interfaz que va a manejar la función SCCP en nuestro caso es la tarjeta PCCS6. Indicador de Mantenimiento: Indica si es una labor de mantenimiento o de operación. SIO: Se incluye aquí el mensaje que se desea transmitir Opciones: Todos los parámetros de configuración que sean necesarios se incluyen aquí. Punto de Código: Se incluye el punto de señalización que debe ser configurado. Max Sif: la longitud máxima de los SIF. Estos parámetros son enviados directamente hacia la interfaz PCCS3 a través de del mensaje SCP_MSG_CONFIG (ver anexo M). 68

69 En este subsistema se declaran cada uno de los subsistemas de señalización con los cuales se interactuará para el envío de los mensajes, y como tal se implementó un programa de monitoreo de estado de subsistemas en cada una de las centrales cooperantes. Para esto se utiliza la función SCCPSubSystemConf (cuyo código y diagrama de flujo se detalla en el Anexo G). Los subsistemas programados por la interfaz son: Mobile Aplication Part Intelligent Netwok Short Message Service Subsystem La definición de estos subsistemas se hace desde el registro de Windows para la configuración de las centrales cooperantes. Para la decodificación y codificación de los subsistemas se preparó una estructura denominada ssn con la siguiente información: Una vez en operación el subsistema SCCP debe controlar cada uno de los procesos. En ese momento la administración de los mensajes es manejada por el procedimiento ProcessSCCPMsgReceive (Ver Anexo I), el cual es ejecutado por el procedimiento ThreadSCCPMsgReceive (Ver anexo K) que lo lanza como un hilo de programación, cada vez que llega un mensaje desde el subsistema MTP. Cuando el mensaje se recibe se toma el contenido y se llama al procedimiento ProcessMsg (Ver Anexo L) que hace la parte de decodificación de SCCP a través 69

70 de la función SCCPDecode (Ver Anexo E), se valida a través de estos procedimientos el tipo de componente y la especificación de la operación, si corresponde a una solicitud o respuesta, se envía el mensaje decodificado al subsistema transaccional. En la Figura 11 se muestra la ubicación de la información suministrada por el subsistema SCCP a nuestra Interfaz de usuario. Figura 11. Información de SCCP en Interfaz de Usuario La parte de control y verificación de cada uno de los estados de los subsistemas se ejecuta a través del procedimiento SCCPReadStatus (Ver Anexo F), que envía el mensaje SCP_MSG_R_SSR_STATS (Ver Anexo M) y se espera la respuesta desde el subsistema MTP. 70

71 El subsistema SCCP espera la llegada desde el subsistema transaccional de los return result de cada una de las transacciones enviadas por él. Una vez que la recibe empaqueta el mensaje utilizando el procedimiento BuildSCCP(Ver Anexo D) y el resultado lo envía al subsistema MTP utilizando la función SendMessageSCCP Subsistema Transaccional Este subsistema se compone de un decodificador de mensajes y de una interfaz de consulta. El decodificador recibe el mensaje TCAP y evalúa antes de ser decodificado que provenga de un INVOKE y sea originado por un OCANOT (Origination Call Access Notification), entonces se procede a la decodificación del contenido de la MSU utilizando para esto la función TCAPDecode (Ver Anexo N) que extrae el contenido TCAP y luego se decodifica el contenido IS41 del mensaje a través de la función IS41Decode (Ver Anexo O). Se ejecuta el procedimiento ProcessOCANOTMsg (Ver Anexo Q), el cual captura los parámetros del usuario y los almacena en una estructura llamada UserData que contiene los siguientes parámetros TCAP de la transacción. En ella se verifica la existencia o no del serial del equipo; con esta simple comparación se sabe si la llamada fue originada por un subscriptor móvil o provino de una interconexión (comparación necesaria al momento de implementar un nivel de inteligencia de red). Cuando el sistema de consulta da una respuesta a nuestra transacción se realiza el empaquetamiento de la misma a través del procedimiento BuildTCAPReturnResult, que se encarga de generar a partir de los datos recibidos un Return Result hacia la central que genero el Invoke. Este mensaje es enviado nuevamente al subsistema SCCP. 71

72 3.1.4 Subsistema de Consulta Una vez identificado el tipo de transacción y decodificado el mensaje se procede a generar las solicitudes al módulo de base de datos. Este módulo es una extensión del subsistema transaccional y está compuesto por librerías de Sybase para C++ que hacen parte del paquete Open Client. La información hacia el módulo de base de datos se envía utilizando cursores los cuales llevan la identificación de la transacción. Esto permite manejar un numero único de identificación de las transacciones en todo el sistema. Como primer paso se verifica el número de transacción a través de la variable ConnectionQueueLen, luego se activa un puntero para abrir la conexión con la base de datos a través de la función sybaseconnect, una vez establecida la conexión se procede al envío de información hacia el módulo de base de datos, pero esta información se envía clasificada de acuerdo al origen de la transacción (móvil o interconexión): si es de origen móvil se envía el requerimiento al módulo de base de datos a través del procedimiento ProcSolveMin, y si es de origen interconexión se envía a través del procedimiento ProcSolveORG. Esta diferencia radica en que los orígenes de interconexión no poseen componentes de IS41 por lo que no pueden acceder a algunos subsistemas. Al enviar los requerimientos a la base de datos el subsistema espera la respuesta manteniendo activos los punteros. El subsistema de consulta también se encarga de verificar la conexión TCP/IP con la base de datos. Para esto utiliza la librería POWERTCP que basa la conectividad a partir de sockets. Una vez el subsistema de consulta recibe la respuesta a la transacción, envía los datos de la misma al módulo transaccional para que realice las tareas programadas y de inmediato elimina el cursor que había abierto. 72

73 3.2 Módulo de Base de Datos El módulo de base de datos está desarrollado sobre un motor de base de Datos Sybase Adaptive Enterprise y se compone de un grupo de subsistemas formados de tablas, disparadores y procedimientos almacenados. Figura 12. Estructura Módulo Base de Datos Subsistema de Funciones Este subsistema maneja todas las consultas provenientes del módulo SCP y está formado por un grupo de procedimientos almacenados que de acuerdo a la solicitud son ejecutados. El primero de estos procedimientos almacenados es el proc_solve_min (ver Anexo S). Este procedimiento se llama cuando la transacción es de origen móvil, los parámetros que recibe son: Dígitos Marcados, Identificación del Móvil y característica de facturación. Con esta información el procedimiento almacenado 73

74 hace un llamado al subsistema de perfiles y al subsistema de parámetros para devolver una respuesta a la transacción. Dicha respuesta se da en términos del RIC (Routing Interrogation Code) y de los dígitos a enrutar. El segundo de los procedimientos almacenados corresponde al proc_solve_org (Ver Anexo S), el cual está destinado para el análisis de transacciones que no sean de origen móvil. Recibe los mismos parámetros del anterior procedimiento y un campo que indica la forma de facturación. El tercer procedimiento almacenado corresponde al proc_solve_bin (ver Anexo S), el cual se encarga del análisis de numero de A y serial para verificar los perfiles de abonado y dar una respuesta de acuerdo a dicho perfil. El procedimiento realiza una búsqueda dentro de la tabla MOBILEIN (Ver Anexo T) y de ésta extrae el perfil deseado, luego hace un llamado al procedimiento proc_solve_term el cual arroja el ID del usuario dentro de la estructura y las transacciones a las cuales tiene acceso Subsistema de perfiles El subsistema de perfiles está conformado por las tablas que contienen todos los perfiles de usuarios y sus características. Estas tablas forman una relacion de clases las cuales se describen en el anexo R. La figura 13 muestra el modelo de relación entre las tablas. La primera tabla contiene el listado de todos los RICODE y su descripción, es usada como una referencia para todas las respuestas que se deben entregar para las transacciones de TCAP. De esta forma la central cooperante puede traducir los códigos de error o las transacciones exitosas. Esta tabla se denomina ricodein (Ver anexo T). 74

75 La segunda tabla se denomina ListORGIN (ver Anexo T) y contiene todos los números permitidos para cada usuario, las translaciones para estos números y los casos de cobro. La tercera tabla se denomina UserIN (Ver Anexo T), la cual contiene los perfiles de usuario los grupos a lo que pertenece y la identificación. Adicionalmente a éstas, existen otras tablas que especifican el comportamiento de usuarios específicos. Todas estas tablas se describen en el anexo T. El subsistema de perfiles es consultado por el subsistema de consultas de acuerdo a los datos de la transacción y toma los datos que necesita para entregar la respuesta de dicha transacción. Todas las respuestas van acompañadas de un RICODE, el cual indica si la transacción fue exitosa. Figura 13. Modelo de Relacion entre las Tablas 75

76 3.2.3 Subsistema de parámetros Los parámetros dentro del módulo Base de Datos hacen parte del diagrama entidad relación del módulo base de datos. En este subsistema se hace la definición completa de los parámetros de cada transacción. Este subsistema está formado por una familia de Triggers (ver Anexo T) asociados a cada tabla que permite, al momento de ingresar algún nuevo valor, determinar si es un valor válido dentro del perfil del usuario. De igual forma, el subsistema de parámetros permite la creación de nuevos servicios y su correcto funcionamiento Subsistema de Creación de Servicios Para la creación de nuevos servicios se implementó un subsistema que se maneja a través de la aplicación Power Designer SQL Modeler (ver figura 12), con la cual se tiene acceso a toda la base de datos y se pueden hacer cambios dentro de la estructura de la misma. 76

77 Figura 14. Ambiente General SQL Designer Un nuevo servicio implica la creación de un procedimiento almacenado, de una parametrización y de una tabla de perfiles, los cuales deben incluirse de acuerdo a su origen dentro del subsistema transaccional del módulo SCP Subsistema de Mantenimiento Las funciones principales del subsistema de mantenimiento es la de realizar las rutinas que permitan al módulo de base de datos operar correctamente. El subsistema de mantenimiento se lleva a cabo a través de la herramienta SYBASE CENTRAL que viene incluida dentro de la base de datos. Adicionalmente, a través de la programación de tareas de Linux (Crontab) se programan revisiones de consistencia y de integridad a la base de datos. 77

78 Figura 15. Configuración de parámetros Las actividades que se realizan a través de este módulo son: Cambios en la configuración del Servidor (Figura 12). Configuración de usuarios. Creación de tablas y procedimientos almacenados. Backup. Restauración. Verificación de consistencia. Checkpoint. Monitoreo de las propiedades de base de datos. 78

79 Figura 16. Cliente de Administracion de Base de Datos La figura 16 muestra la interfaz de SYBASE Central; el acceso a la interfaz está restringido a los perfiles creados en la configuración del servidor. En la figura 17 se muestra el cuadro de diálogo para el control de acceso; a pesar de ser una herramienta abierta cada uno de los accesos es validado con el servidor principal. Figura 17. Control de Acceso La figura 17 muestra la información que se le suministra al cliente una vez ha ingresado. 79

80 Figura 18. Información suministrada por el Cliente Figura 19. Propiedades de Base de Datos 80

81 4 ESPECIFICACIONES 4.1 Requerimientos del sistema Cada uno de los módulos del sistema funciona de manera independiente, por ende poseen requerimientos individuales que serán detallados a continuación: Requerimientos del Módulo SCP Especificación Valor Sistema Operativo Windows NT 4.0 Plataforma de Desarrollo Visual Studio 5.0 Tamaño del Programa 10.3 Mb Memoria RAM 64 Mb Procesador Intel Pentium II o Superior Resolución de Pantalla 800x600 o superior Conectividad a Red Lan Interfaz de Red 10Mbit/s o Superior Conectividad a Red de Señalización 2048 Kbit/s 75Ω Velocidad de Sincronización 4.8 Kbit/s a 64 Kbit/s PC BUS Tarjeta PCCS6 Slot físico Full-length ISA 16 bit Tabla 10. Requerimientos Módulo SCP 81

82 4.1.2 Requerimientos del Módulo de Base de Datos Especificación Valor Sistema Operativo Linux Red Hat 7.3 Kernel 2.4 Plataforma de Desarrollo SQL Advantage Motor de Base de Datos Sybase Adaptive Server Enterprise Espacio Requerido 46 Mb Memoria RAM 128 Mb Procesador Intel Pentium II o Superior Resolución de Pantalla 800x600 o superior Conectividad a Red Lan Interfaz de Red 10Mbit/s o Superior Protocolo de Conectividad ODBC Sybase Driver Tabla 11. Requerimientos Módulo de Base de Datos Requerimientos de los clientes Especificación Valor Sistema Operativo Windows 98 o Superior Plataforma de Desarrollo Borland delphi 4.0 Cliente de Base de Datos Sybase ODBC Driver Espacio Requerido 5 Mb Memoria RAM 64 Mb Procesador Intel Pentium II o Superior Resolución de Pantalla 800x600 o superior Conectividad a Red Lan Interfaz de Red 10Mbit/s o Superior Tabla 12. Requerimientos de los Clientes 82

83 4.2 Desempeño del sistema El espacio en disco ocupado por el módulo SCP es de 13MB. La utilización de la memoria RAM varía de acuerdo al número de transacciones que esté manejando. En la figura 20 se muestra el estado de la máquina durante la fase de pruebas. El haber diseñado el programa con una estructura de programación basada en hilos de programación permite que sea muy eficiente el uso de los recursos de máquina. Al haber realizado un sistema modular se obtiene bastante flexibilidad en cuanto a los recursos. Todos los módulos que interactúan con el cliente pueden ser instalados en cualquier equipo con sistema operativo Windows 95, NT o superior. El módulo SCP sí esta ligado al sistema operativo Windows NT 4.0 ya que demostró durante las pruebas una gran estabilidad. Figura 20. Desempeño del módulo SCP 83

84 El módulo de base de datos ocupa al 100% la capacidad de la máquina instalada y administra los recursos de manera exclusiva. Dentro de la configuración del motor de base de datos se le configura el total dominio de los discos duros y de la memoria RAM. De la misma forma que el módulo SCP la base de datos hace un uso de Discos y Memoria por demanda. El sistema operativo Linux resultó una solución excelente para la base de datos por su escalabilidad, seguridad y estabilidad. Figura 21. Utilización Log de transacciones La Figura 21 muestra la utilización del Log de la base de datos. Esta información indica el volumen transaccional que mantiene en memoria la base de datos. La tabla 12 muestra la configuración de memoria RAM implementada dentro de la base de datos y el valor utilizado durante la fase de pruebas. Parametro Default Memoria usada Valor Configurado Valor Utilizado Memoria Total Tabla 12. Configuración de Memoria 84

85 La figura 22 muestra el espacio físico que está utilizando la base de datos en cada uno de sus segmentos. Figura 22. Utilización Espacio Físico Servidor de Base de Datos 85

86 5 EVALUACION Y ANALISIS DE RESULTADOS La actual configuración de la red de señalización de la empresa COMCEL- CELCARIBE se convirtió en el escenario sobre el cual se configuraron y se realizaron las pruebas del sistema. Para esto se hizo un estudio preliminar de la configuración de la red de señalización, identificando todos los elementos de red existentes, los tipos de enlaces de señalización utilizados y las transacciones típicas realizadas por estos. La segunda fase de las pruebas se basaron en las recomendaciones Q.780, Q.781 de la ITU-T, las cuales establecen los escenarios de pruebas de nuevos elementos de red a incorporarse en una red de señalización. La tercera fase fue la implementación de dos servicios dentro del SCP con lo cual se realizó la prueba de las transacciones con el motor de base de datos y la interacción del sistema con los elementos de la red de señalización. Durante este capítulo se describirá cada una de las fases, las pruebas involucradas, los resultados obtenidos y el análisis de los mismos. 5.1 Estudio Preliminar de la Red de Señalización En el anexo A, se muestra el diagrama genérico actual de la red de señalización sobre la que se instaló el sistema, a continuación se mostrará en detalle los elementos de red existentes: Diagrama de Red La figura 23 muestra en detalle el diagrama de la red de señalización existente. En ella se observan 3 elementos de Red que desempeñan la función de punto de 86

87 transferencia de señalización. De igual forma se observan los enlaces de señalización entre cada uno de los elementos de red. En este diagrama se detallan únicamente las conexiones ANSI de la red, que para el caso de la telefonía móvil utilizan el protocolo IS-41. Figura 23. Diagrama de Red de Señalización 87

88 5.1.2 Especificaciones Elementos de Red Los elementos de red más importantes que componen la red de señalización de COMCEL-Celcaribe son: MSC 5000: Central de conmutación marca Ericsson, utilizada para el manejo de tráfico celular TDMA. Esta central desempeña el papel de VLR y MSC, controlando todos los procesos de llamada para los usuarios en su area de servicio. Está configurada como SPP y STP, permitiendo hacer gateway de mensajes de señalización enviados hacia otros puntos. Su punto de código es el MSC : Central de conmutación marca Nortel, desempeña el papel de VLR, HLR y MSC. Está configurada como SPP y STP. Se convierte en el HLR de todos los abonados de la MSC MSC : Central de conmutación marca Nortel, desempeña el papel de VLR, HLR y MSC. Está configurada como SPP y STP. Verisign: Servidor de validación perfiles Roamers internacionales. Este servidor emula a un HLR y permite identificar los perfiles de los abonados internacionales que se encuentran haciendo Roaming en la MSC SMSC: Centro de mensajes cortos, es un elemento de red que se encarga de dar trámite a los SMS s con origen o destino abonados celulares Servicios disponibles Los servicios que ofrecen estos elementos de red entre ellos son: 88

89 Establecimiento de llamadas. Intercambio de perfiles. Enrutamiento de números temporales. Validación de perfiles de abonado. Envío de Mensajes de Texto Transacciones Todas las transacciones que tienen lugar en la red de señalización a nivel de ANSI son efectuadas utilizando el protocolo IS-41 y se basan en eventos de llamada, originación, terminación, envío y recepción de mensajes de texto. 5.2 Pruebas recomendaciones ITU-T Dentro del proceso de pruebas se eligieron las recomendaciones de la ITU-T que estaban ligadas al funcionamiento de nuestro sistema, es decir, aquellas que se orientan a validar los mensajes y procesos de las capas MTP, SCCP y TCAP. Todas las pruebas están orientadas a la validación de las funciones y características de funcionamiento del sistema de acuerdo con las recomendaciones de la ITU-T que rigen el sistema de señalización por canal común SS Pruebas de la Capa MTP Para la realización de esta prueba se utilizó un analizador de protocolos marca Hewlett Packard Signaling Test Set y se configuró el esquema que muestra la figura

90 Figura 24. Configuración de Prueba Nivel MTP En cada una de las pruebas descritas se utilizó la central Ericsson, que como la recomendación lo indica, debe utilizarse un elemento de red ya validado Pruebas de control de estado de Enlace Inicialización: Se inicia el set de pruebas con el enlace de señalización conectado entre los dos puntos, pero sin activar el link de señalización. Una vez preparado el analizador activamos el link de señalización, el orden y valor de los mensajes según la norma Q.703 debe ser FIB=BIB=1,FSN=BSN=127, como se observa en la figura 25 la prueba sale exitosa. 90

91 Figura 25. Inicialización del sistema Mensajes de Mantenimiento de Enlace: Una vez inicializado el sistema se procede a verificar la comunicación de mensajes de mantenimiento entre los dos elementos de red. Figura 26. Mensajes de Mantenimiento 91

92 La figura 265 muestra los mensajes de mantenimiento enviados entre la central Ericsson y nuestro SCP: estos mensajes se componen de un mensaje de mantenimiento inicial enviado desde nuestro módulo y una respuesta enviada desde la central. En las figuras 27 y 28 se muestran los mensajes obtenidos durante esta prueba. Figura 27. Mensaje enviado desde el SCP 92

93 Figura 28. Respuesta Obtenida por la MSC Ericsson Fallo en Enlace: En este punto lo que se hizo fue interrumpir el canal de recepción del enlace de señalización. Ante esta falla lo primero que hace nuestro SCP es enviar un mensaje de mantenimiento de enlace. Al no obtener respuesta envía el mensaje de prueba de ruta de señalización para destinos prohibidos. Este mensaje es mostrado en la figura 29. El SCP envía este mensaje cada 2 segundos hasta encontrar respuesta por la SMC. Una vez se levanta el link, el otro elemento de red debe contestar el mensaje. Obtenida la respuesta, el link volvió a activarse. En las figuras 30 y 31 se muestra la secuencia de los mensajes obtenidos y la decodificación del mensaje de respuesta respectivamente. 93

94 Figura 29. Mensaje de Pruebas de enlace Figura 30. Secuencia Mensajes de Estado 94

95 Figura 31. Mensaje de respuesta 5.3 Pruebas Funcionales Las pruebas funcionales permiten validar a partir de un servicio la correcta operación de todos los elementos que componen el sistema. El servicio elegido fue el de directorio de llamadas, en el cual un abonado solo puede generar llamadas a un grupo de teléfonos; cualquier número telefónico que no pertenezca al grupo será rechazado Configuración del Ambiente 1. Se configuró en la MSC Ericsson una ruta de tipo MORIG que enviará un OCANOT hacia el punto de señalización que será una central cooperante (ver Anexo C). 95

96 2. Se estableció un análisis de dígitos que diera como resultado el enrutamiento a través de la ruta MORIG creada (ver Anexo C). 3. Se configuró un móvil en la central de conmutación que enrutara todas sus llamadas hacia el análisis de dígitos creado (ver Anexo C). 4. Se creó en la base de datos de la aplicación un perfil para el abonado de tal forma que solo le permitiera marcar determinados números y le restringiera las llamadas a los demás. 5. se configuró en la central una respuesta para el RIC code que fuese devuelto por el SCP (Ver Anexo C). 6. Se conectó el analizador para monitorear los mensajes entre el SCP y la MSC Parámetros de la Prueba Los parámetros de entrada para la prueba serán los dígitos marcados por el abonado; los parámetros de salida serán el mensaje de respuesta de la MSC que será un correcto enrutamiento en caso de ser una transacción permitida o el desvío a un mensaje de error en caso de ser una transacción no autorizada. La figura 32 muestra el diagrama de la prueba con los mensajes involucrados en todos los procesos de la llamada. 96

97 MS MSC Maquina de Anuncios SCP DB 1. Digitos+SND 2. OCANOT INVOKE (Mobile_id, Digits Dialed, ESN) 3.Mob_call(Mobilei d,digits Dialed) 4.Route_call(CPI, RouteDigits,Setup Code, ACD) 5. OCANOT RETURN RESULT (CPI, Digits Routing, Setup Code,ACD) 6. IAM 7. REL Llamada Establecida Figura 32. Diagrama de MensajesPrueba Funciónal Resultados Los resultados obtenidos se certifican con los traces obtenidos del analizador de protocolos que se instaló monitoreando el link de señalización en la configuración que muestra la figura 23. Al generar la llamada se logró enrutar correctamente a través de la ruta de REDINMH, creada para este propósito. La llamada genera un disparo hacia el SCP enviando el OCANOT, como se esperaba. Al llegar el mensaje al módulo 97

98 SCP se generó la decodificación del mensaje y el inicio de una transacción en la base de datos. A través del cliente de administración de sybase se pudo constatar la conexión. En la base de datos se programó para el número una respuesta no válida a la primera transacción enviando el RICODE 50 que se tradujo en la central de conmutación como un mensaje de no disponibilidad de servicio. En el analizador se observó el mensaje enviado del módulo SCP hacia la central de conmutación un return result que contenía el mensaje de falla. En un siguiente intento se configuró una traducción de digitos, es decir, que todos los digitos marcados por el número de pruebas se tradujeran como una marcación al *611. Con esta nueva configuración se realizó la prueba encontrando en el return result la secuencia de dígitos programada, resultando la prueba satisfactoria. Para esta configuración de servicios se trabajó con el mensaje de originación desde abonados móviles, siendo muy completo por la información que contiene. Este mensaje fue decodificado manualmente debido a que presenta modificaciones de la norma realizadas por el fabricante de la central utilizada para las pruebas. 98

99 6 LIMITACIONES Y POSIBLES MEJORAS 6.1 Limitaciones del sistema El sistema es altamente dependiente de la conexión a la base de datos: una interrupción del enlace hace que se pierda la secuencia en la conexión. Esto se solucionó instalando una doble tarjeta de red en la máquina que contiene el Módulo SCP. El manejo de memoria por parte del servidor de base de datos es estricto por lo que esa máquina solo puede tener este servicio activado. El módulo SCP esta diseñado para funcionar con MS Windows NT 4.0. Se probó en otros sistemas operativos sin tener un buen desempeño. La elección de este sistema operativo se hizo teniendo en cuenta la baja demanda de recursos de máquina para las funciones de sistema operativo y funcionó muy bien. El número de conexiones a la base de datos está limitada por la licencia adquirida y por el consumo de memoria del servidor. Ampliar esta capacidad implica un aumento en los costos de licenciamiento. La configuración solo permite interpretar los mensajes orientados con llamadas en IS-41 y para la central Ericsson, para interpretar mensajes de otros fabricantes se debe modificar los parámetros de configuración. 99

100 6.2 Posibles Mejoras El sistema está creado como un SCP por lo que hacer una implementación de un modelo de Inteligencia de Red sería un avance muy apropiado ya que se utilizaría el nodo como un elemento de red completo. El manejo de los protocolos podría implementarse no como algo fijo dentro del programa principal sino a manera de archivos de configuración que proporcionarán una mayor flexibilidad a la hora de cambios o mejoras dentro de los estándares y recomendaciones de los entes normativos. Para la configuración de la base de datos se puede pensar en montar el motor en un servidor con plataforma multiprocesador y configuración de discos redundantes, lo cual le proporcionaría al sistema un mayor respaldo. 100

101 CONCLUSIONES El objetivo general del proyecto fue alcanzado con el diseño de un service control point y su plan de implementación dentro de una red de telefonía móvil de primera generación. El sistema diseñado e implementado cumplió con todos los requisitos planteados y se observó un comportamiento óptimo. De acuerdo al estado del arte de estos sistemas en el contexto local se puede establecer que este desarrollo contribuye a la investigación en el campo de la señalización por canal común y en la construcción de aplicaciones basadas en la misma. A pesar de haber centrado la investigación inicial del proyecto en TCAP como elemento vital del desarrollo, al transcurrir el proyecto observamos que para capturar la información de llamada de los clientes solo es necesario el mensaje Origination Call Access Notification (OCANOT). Sin embargo, se desarrolló todo un algoritmo de descodificación del protocolo TCAP y de IS-41. La importancia de la sincronía en la alineación del enlace se hizo evidente durante la fase inicial del proyecto, ya que hasta no lograr comprender el comportamiento del reloj de la interfaz no se pudo lograr una comunicación de primer nivel con la central de conmutación. Ericsson tiene para ciertos procesos ligados con el tratamiento de la llamada variaciones a la norma IS-41. Se observó esta variación con la descodificación inicial de los mensajes hacia el HLR y las centrales cooperantes ya que el analizador de protocolos no era capaz de decodificar estos mensajes y fue 101

102 necesario decodificarlos manualmente luego de obtener por parte del fabricante los códigos de cada componente. Se obtuvo un modelo de llamada a partir de las pruebas realizadas, el cual puede servir de base para futuras implementaciones. En este modelo se identifican todos los entes ligados al procesamiento de la llamada y los mensajes que intervienen. La tarjeta escogida como interfaz del sistema se convirtió en una excelente elección, por sus innumerables recursos. Adicionalmente, el fabricante brindó el soporte necesario para la solución de las dudas. Esta interfaz demostró a lo largo del proyecto una gran escalabilidad y flexibilidad para los requerimientos. El diseño de la base de datos se convirtió en pieza clave dentro del proceso de investigación. Sin embargo, el modelo final se destacó por su sencillez y eficiencia ya que se basó en procedimientos almacenados que eran llamados desde el módulo SCP, lo que mejoró los tiempos de respuesta notablemente al no enviar grandes volúmenes de datos en cada transacción si no solo enviar las variables de entrada y el nombre del procedimiento. Los procesos hijos empleados en la aplicación asemejan la capa de capacidad de transacción obteniendo procesos independientes identificados con un ID; esto permitió adecuar las estructuras y clases utilizadas a las recomendaciones de ITU- T en la parte de capacidades de transacción. La longitud de los indicadores de transacción se convirtió en un problema a la hora de probar en su totalidad el sistema ya que la central lleva un consecutivo de todos los mensajes que ha enviado a los elementos de red. Inicialmente se consideró que este ítem iniciaría en 0x0 pero ya tenía un valor inicial. Por esto se utilizó un rastreo a nivel de Ericsson para identificar la longitud actual del ID y ajustar nuestro sistema para que se adaptara a dicho valor. 102

103 Las pruebas realizadas en la parte de MTP se basaron en extractos de las recomendaciones de la ITU-T pero estaban orientadas a probar la estabilidad del sistema y la capacidad para integrarse con la red de señalización. Una vez realizadas las pruebas se pudieron ajustar los parámetros de la interfaz para un mejor funcionamiento. La creación de decodificadores para cada uno de los tipos de mensajes y de constructores de respuestas para los mismos hizo que el software fuera muy extenso y rígido. Esto hace pensar en una implementación basada en archivos de configuración que sean analizados por el core. Linux como sistema operativo para el motor de base de datos cumplió con las expectativas de estabilidad necesarias para la base de datos y para la disminución de los costos de implementación. Los monitores de estado de enlace y subsistemas desarrollados durante el proyecto funcionaron de acuerdo a las especificaciones de diseño, aprovechando los mensajes de mantenimiento de link enviados por la central. Luego se implementó un mensaje inicial de verificación de subsistemas que permitía recopilar la información. Sin embargo, con la utilización de los recursos de la tarjeta estas dos operaciones se simplificaron hasta convertirse en una clase que activaba un recurso en la tarjeta de señalización. El estudio de la red de señalización y de las características de la central Ericsson permitieron adaptar el diseño del sistema a unos estándares comerciales sin apartarnos del ámbito académico que rodeó el desarrollo del proyecto. 103

104 BIBLIOGRAFÍA Y FUENTES DE INFORMACIÓN [1]. Homa, Jonathan, Intelligent Network Requirements for Personal Communications Services, IEEE Communications Magazine, Vol 1., 2, [2]. Garrahan, James, Russo, Peter, et al., Intelligent Network Overview, IEEE Communications Magazine, March, [3]. CCITT Study Group XI, Q.1211: Introduction to Intelligent Network Capability Set 1, COM XI-R 210-E, April, [4]. CCITT Study Group XI, Recommnedation Q.1202: Intelligent Network Service Plane architecture, October, 1992 [5]. BENITO REVOLLO, Andrés, Proyecto de trabajo de grado No 0418, Pontificia Universidad Javeriana, Departamento de Electrónica [6]. CCITT Study Group XI, ITU-T Recommendation Q.1205: Intelligent Network Physical Plane architecture, March, [7]. CCITT Study Group IV, M.3010: Principles for a Telecommunications Management Network, [8]. GÓMEZ HERRERA, Clara Liliana, Propuesta de una metodología de desarrollo de servicios de red inteligente. Bogotá 1996, 552 p. Tesis (Magíster en Ingeniería de Sistemas y Computación). Universidad de los Andes. Facultad de Ingeniería. Área de Sistemas. 104

105 [9]. BAYONA BOLAÑOS, Oswaldo, Interconexión de bases de datos sobre interfaz abierta para prestación de nuevos servicios de Red Inteligente. Bogotá 1999, 170 p. Tesis (Magíster en Ingeniería Eléctrica). Universidad de los Andes. Facultad de Ingeniería. Área de Eléctrica. [10]. ALVAREZ, Vladimir y ROSAS, Martín, Desarrollo de Servicios para Telefonía de Larga Distancia sobre Internet, Basados en Red Inteligente. Bogotá 1999, 170 p. Tesis (Magíster en Ingeniería Eléctrica). Universidad de los Andes. Facultad de Ingeniería. Área de Eléctrica. [11]. Lehtinen, Pekka, Performance and Overload Modelling of SCP and SSPS of an IN, Workshop proceedings: Workshop on Intelligent Networks, Lappeenranta University of Technology, 1993 [12]. CCITT Grupo de estudio XI, ITU-T Recomendación Q.721: Descripción funciónal de la parte control de la conexión de señalización, Julio de [13]. CCITT Grupo de estudio XI, ITU-T Recomendación Q.771: Descripción funciónal de las capacidades de transacción, Junio de [14]. CCITT Grupo de estudio XI, ITU-T Recomendación Q.700: Introducción al sistema de señalización N. 7 del CCITT, Marzo de [15]. KRUGLINSKI, David J. Inside Visual C++, Microsoft Press, 5ta Edición, pp 17-47, , Washington USA, [16]. Ambrosch, W., The Intelligent Network, A joint study by Bell Atlantic, IBM and Siemens, Germany, 1989 [22]

106 [23]. [24]. [25]

107 ANEXOS Anexo A. Análisis estado Actual y Futuro Red de Señalización Estado Actual INTERNATIONAL ROAMING LS= (S7ST-9) S.C.P/STP PARC MSC, VLR,STP S.S.P. LS= (S7ST-0) LS= (S7ST-1) OCCPER MEDELLIN STP CALI BUCARAMANGA BOGOTA STP/SCP/Ac/HLR BOGOTA STP/SCP BOGATA 2 Actualmente la red de señalización del operador celular Celcaribe S.A cuenta con una central de conmutación Ericsson AXE 10 con referencia MSC 5000, la cual desempeña las funciones de SSPC y STP, las funciones de HLR son desempeñadas por otra central y estan enlazadas a través de links de señalización, manejando el protocolo IS-41 para la transmisión de los mensajes entre el VLR y el HLR. El enrutamiento de funciones especiales se hace a través de links de señalización ISUP. 107

108 Bajo este esquema la red de señalización no cuenta con entidades especializadas para el manejo de funciones especificas ni para implementación de nuevos servicios. Al momento de implementar cualquier cambio se debe modificar todos los enrutamientos dentro de los elementos de red (HLR, MSC y VLR). De igual forma todo tipo de interacciones que se deseen efectuar entre los usuarios y elementos de red que no se encuentren asociados a la tecnología de comunicación debera hacerse a través de un canal de voz, por ejemplo consultas de saldo, activación de servicios, concursos, etc. Estado Futuro INTERNATIONAL ROAMING S.C.P. LS= (S7ST-5) LS= (S7ST-9) S.C.P/STP PARC MSC, VLR,STP S.S.P. LS= (S7ST-0) LS= (S7ST-1) OCCPER MEDELLIN STP CALI BUCARAMANGA BOGOTA STP/SCP/Ac/HLR BOGOTA STP/SCP BOGATA 2 Una vez implementado el SCP se observa dentro de la red de señalización un nuevo elemento de red el cual cumple con las funciones de SSCP, la central de conmutación sigue manteniendo su condicion de SSCP y de STP, sirviendo de punto de tranferencia de señalización para todos los mensajes enviados desde elementos de red cooperantes hacia el SCP, dentro de la red es necesario definirle a cada uno de los elementos de Red el SPC del SCP. 108

109 A nivel de funciones de red el SCP puede conectarse con otros elementos que no hagan parte de la red de señalización utilizando la red de datos (LAN); bajo este esquema el acceso a servicios que no esten asociados con las funciones basicas de una llamada pueden enrutarse hacia el SCP el cual se encargara de su procesamiento, de igual forma se pueden implementar nuevos servicios sin hacer cambios en un gran numero de elementos de red, unicamente cambiando los parámetros de configuración del SCP. La red de señalización queda preparada para la instalación de un esquema de red inteligente. 109

110 Anexo B. Procedimientos para manejo de MTP void ProcessMtpMsgResume(HDR* hdr, CApolloView* view) CApolloDoc* doc = view->getdocument(); _MSG* m = (_MSG *)hdr; u8* p; p = get_param(m); u32 upointcode; u8 upointdata; SP* ptrsp; int nimage,nselectimage; CString strvalue; upointcode = 0x ; upointdata = 0x00; upointdata = p[3]; upointcode = upointdata; upointdata = p[2]; upointcode = (upointdata << 8); upointdata = p[1]; upointcode = (upointdata << 16); ptrsp = doc->findsp(upointcode); if (ptrsp!= NULL) ptrsp->ustatus = SP_STATUS_MTP_RESUME; strvalue = " MTP Resume"; nimage = BMP_SP_OK; nselectimage = BMP_SP_OK; CString strresult = NumberToString(ptrSP->uSPAll); 110

111 strresult = ptrsp->strname + " " + strresult + strvalue; view->m_ctreemaint.setitem(ptrsp->hitem, TVIF_IMAGE TVIF_TEXT TVIF_SELECTEDIMAGE, strresult, nimage, nselectimage, NULL, NULL, NULL); void ProcessMtpMsgPause(HDR* hdr, CApolloView* view) CApolloDoc* doc = view->getdocument(); _MSG* m = (_MSG *)hdr; u8* p; p = get_param(m); u32 upointcode; u8 upointdata; SP* ptrsp; int nimage,nselectimage; CString strvalue; upointcode = 0x ; upointdata = 0x00; upointdata = p[3]; upointcode = upointdata; upointdata = p[2]; upointcode = (upointdata << 8); upointdata = p[1]; upointcode = (upointdata << 16); ptrsp = doc->findsp(upointcode); if (ptrsp!= NULL) ptrsp->ustatus &= ~(SP_STATUS_MTP_RESUME); 111

112 strvalue = " MTP Pause"; nimage = BMP_SP_BAD; nselectimage = BMP_SP_BAD; CString strresult = NumberToString(ptrSP->uSPAll); strresult = ptrsp->strname + " " + strresult + strvalue; view->m_ctreemaint.setitem(ptrsp->hitem, TVIF_IMAGE TVIF_TEXT TVIF_SELECTEDIMAGE, strresult, nimage, nselectimage, NULL, NULL, NULL); void ProcessMgtMsgMtpEvent(HDR* hdr, CApolloView* view) CApolloDoc* doc = view->getdocument(); _MSG* m = (_MSG *)hdr; u8* p; u8 ulinkref; u8 ulinkset; LINK_SET* ptrlinkset; CString strvalue; int nimage,nselectimage; u32 upointcode; u8 upointdata; SP* ptrsp; switch (m->hdr.status) case MTPEV_CO: case MTPEV_CB: case MTPEV_REST: case MTPEV_RPO: 112

113 case MTPEV_RPO_CLR: case MTPEV_CONG: case MTPEV_CONG_CLR: case MTPEV_CONG_DIS: p = get_param(m); ulinkset = p[0]; ulinkref = p[1]; ptrlinkset = doc->findlinkset(ulinkset); if (ptrlinkset!= NULL) BOOL bfound = false; int nindex = 0; for (int i = 0; i < MAX_LINK_REF &&!bfound; i++) if (ptrlinkset->ulinkref[i].ustatus!= STAT_EMPTY) if (ptrlinkset->ulinkref[i].ulinkrefid == ulinkref) bfound = true; nindex = i; if (bfound) switch (m->hdr.status) case MTPEV_CO: 113

114 strvalue=" Changeover"; nimage=bmp_sl_ok; nselectimage=bmp_sl_ok; break; case MTPEV_CB: strvalue=" Changeback"; nimage=bmp_sl_ok; nselectimage=bmp_sl_ok; break; case MTPEV_REST: strvalue=" Restoration commenced"; nimage=bmp_sl_bad; nselectimage=bmp_sl_bad; break; case MTPEV_RPO: strvalue=" Remote processor outage"; nimage=bmp_sl_bad; nselectimage=bmp_sl_bad; break; case MTPEV_RPO_CLR: strvalue=" Remote processor outage cleared"; nimage=bmp_sl_ok; 114

115 nselectimage=bmp_sl_ok; break; case MTPEV_CONG: strvalue=" Signalling link congestion"; nimage=bmp_sl_bad; nselectimage=bmp_sl_bad; break; case MTPEV_CONG_CLR: strvalue=" Congestion cleared"; nimage=bmp_sl_ok; nselectimage=bmp_sl_ok; break; case MTPEV_CONG_DIS: strvalue=" MSU discarged due to congestion"; nimage=bmp_sl_bad; nselectimage=bmp_sl_bad; break; CString strresult = NumberToString(ptrLinkSet- >ulinkref[nindex].ulinkrefid); strresult ="LINK "+strresult + strvalue; view->m_ctreemaint.setitem(ptrlinkset->ulinkref[nindex].hitem, TVIF_IMAGE 115

116 TVIF_TEXT TVIF_SELECTEDIMAGE, strresult, nimage, nselectimage, NULL, NULL, NULL); break; case MTPEV_LS_LOST: case MTPEV_LS_OK: case MTPEV_TFP_SENT: case MTPEV_TFA_SENT: p = get_param(m); ulinkset = p[0]; ptrlinkset = doc->findlinkset(ulinkset); if (ptrlinkset!= NULL) switch (m->hdr.status) case MTPEV_LS_LOST: strvalue = " Link Set Failure"; nimage = BMP_LS_BAD; nselectimage = BMP_LS_BAD; break; case MTPEV_LS_OK: strvalue = " Link Set recovered"; 116

117 nimage = BMP_LS_OK; nselectimage = BMP_LS_OK; break; case MTPEV_TFP_SENT: strvalue = " Transfer prohibited broadcast"; nimage = BMP_LS_BAD; nselectimage = BMP_LS_BAD; break; case MTPEV_TFA_SENT: strvalue = " Transfer allowed broadcast"; nimage = BMP_LS_OK; nselectimage = BMP_LS_OK; break; CString strresult = NumberToString(ptrLinkSet->uLinkSetId); strresult ="LINK SET " + strresult + strvalue; view->m_ctreemaint.setitem(ptrlinkset->hitem, TVIF_IMAGE TVIF_TEXT TVIF_SELECTEDIMAGE, strresult, nimage, nselectimage, NULL, NULL, NULL); break; case MTPEV_DEST_LOST: case MTPEV_DEST_OK: 117

118 case MTPEV_AJSP_LOST: case MTPEV_AJSP_OK: p = get_param(m); upointcode = 0x ; upointdata = 0x00; upointdata = p[3]; upointcode = upointdata; upointdata = p[2]; upointcode = (upointdata << 8); upointdata = p[1]; upointcode = (upointdata << 16); ptrsp = doc->findsp(upointcode); if (ptrsp!= NULL) switch (m->hdr.status) case MTPEV_DEST_LOST: strvalue = " Destination unavailable"; nimage = BMP_SP_BAD; nselectimage = BMP_SP_BAD; ptrsp->ustatus &= ~(SP_STATUS_AVAILABLE); break; case MTPEV_DEST_OK: strvalue = " Destination available"; nimage = BMP_SP_OK; nselectimage = BMP_SP_OK; 118

119 ptrsp->ustatus = (SP_STATUS_AVAILABLE); break; case MTPEV_AJSP_LOST: strvalue = " Adjacent SP inaccesible"; nimage = BMP_SP_BAD; nselectimage = BMP_SP_BAD; ptrsp->ustatus &= ~(SP_STATUS_ADJ_ACCESIBLE); break; case MTPEV_AJSP_OK: strvalue = " Adjacent SP accesible"; nimage = BMP_SP_OK; nselectimage = BMP_SP_OK; ptrsp->ustatus = (SP_STATUS_ADJ_ACCESIBLE); break; CString strresult = NumberToString(ptrSP->uSPAll); strresult = ptrsp->strname + " " + strresult + strvalue; view->m_ctreemaint.setitem(ptrsp->hitem, TVIF_IMAGE TVIF_TEXT TVIF_SELECTEDIMAGE, strresult,nimage, nselectimage, NULL, NULL, NULL); break; 119

120 Anexo C. Configuración de Parámetros de Señalización Central Ericsson Configuración del terminal de señalización Estado de Link de señalización Estado de Conexión de las Rutas de Señalización 120

121 Configuración de desbordes Configuración del punto de señalización como central cooperante Configuración de la marcación para activar evento Configuración de caso de enrutamiento

122 Configuración de Ruta Configuración TCAP 122

123 Anexo D. Procedimiento BuildSCCP 123

124 Anexo E. Función SCCPDecode int SCCPDecode(_MSG *m, u8 *user_data, u8 *calling_addr) // _MSG : Message issued to PCCS3 card // user_data : Structure to return TCAP part of the message // Whole function returns length of TCAP part of the message u8 cadena[max_string]; int nlen, nlenuserdata; int nlencallingaddr; int nindex; int ndummy; int bsw; int i; nlen = ParamToRec(m, cadena); #ifdef _DEBUG_DECODE DisplayHex(cadena, nlen); #endif nlen--; if (cadena[0] == SCPPT_N_UNITDATA_IND) bsw = TRUE; nindex = 1; while (bsw) // Falta por procesar switch (cadena[nindex]) case SCPPN_SEQ_CTRL: nindex += cadena[nindex + 1] + 2; break; case SCPPN_RET_OPT: nindex += cadena[nindex + 1] + 2; break; case SCPPN_CALLED_ADDR: nindex += cadena[nindex + 1] + 2; break; case SCPPN_CALLING_ADDR: if (calling_addr!= NULL) nlencallingaddr = cadena[nindex + 1]; for (i = 0; i < nlencallingaddr; i++) calling_addr[i + 1] = cadena[nindex + i + 2]; calling_addr[0] = nlencallingaddr; nindex += cadena[nindex + 1] + 2; break; case SCPPN_USER_DATA: nlenuserdata = cadena[nindex + 1]; 124

125 for (i = 0; i < nlenuserdata; i++) user_data[i] = cadena[nindex + i + 2]; nindex += nlenuserdata + 2; break; if (nindex >= nlen) bsw = FALSE; else if (cadena[0] == SCPPT_N_NOTICE_IND) // Not yet supported return(nlenuserdata); 125

126 Anexo F. Procedimiento SCCPReadStatus void SCCPReadStatus(u8 ModuleId, u8 SSRType, u8 SSN, u32 SPC) // ModuleId: // SSRType : // SSN : // SPC : _MSG *m; u16 cmd; u8 *pptr; cmd = SCP_MSG_R_SSR_STATS; if ((m = getm(cmd, 0, RES_REQ_FOR_API, 32))!= 0) m->hdr.src = ModuleId; m->hdr.dst = SCP_TASK_ID; m->hdr.status = 0; pptr = get_param(m); memset(pptr, 0, m->len); rpackbytes(pptr, 1, SSRType, 1); if (SSRType == SCP_RSP) rpackbytes(pptr, 2, SPC, 4); else if (SSRType == SCP_RSS) rpackbytes(pptr, 2, SPC, 4); rpackbytes(pptr, 6, SSN, 1); else if (SSRType == SCP_LSS) rpackbytes(pptr, 6, SSN, 1); if (GCT_send(m->hdr.dst, (HDR *)m)!= 0) printf("failed to send the SCCP_RESPUESTA msg.\n"); relm((hdr *)m); // WaitUntil(ModuleId, cmd & ANSWER_MASK); // WaitUntil(ModuleId, NULL); 126

127 Anexo G. Procedimiento SCCPSubSystemConf void SCCPSubSystemConf(u8 usourcemodid, u8 ModuleId, u8 MultInd, u8 SSRType, u32 PointCode, u8 SSN) // ModuleId : // MultInd : // SSRType : // PointCode: // SSN : _MSG *m; u16 cmd; u8 *pptr; cmd = SCP_MSG_CNF_SSR; if ((m = getm(cmd, 0, (1 << ((ModuleId) & 0x0f)), SCPML_CNF_SSR))!= 0) m->hdr.src = usourcemodid; m->hdr.dst = SCP_TASK_ID; pptr = get_param(m); memset(pptr, 0, m->len); if (SSRType == SCP_RSP) rpackbytes(pptr, SCPMO_CNF_SSR_ssr_type, SSRType, SCPMS_CNF_SSR_ssr_type); rpackbytes(pptr, SCPMO_CNF_SSR_spc, PointCode, SCPMS_CNF_SSR_spc); rpackbytes(pptr, SCPMO_CNF_SSR_ssr_flags, 0x02, SCPMS_CNF_SSR_ssr_flags); else if (SSRType == SCP_RSS) rpackbytes(pptr, SCPMO_CNF_SSR_ssr_type, SSRType, SCPMS_CNF_SSR_ssr_type); rpackbytes(pptr, SCPMO_CNF_SSR_spc, PointCode, SCPMS_CNF_SSR_spc); rpackbytes(pptr, SCPMO_CNF_SSR_ssn, SSN, SCPMS_CNF_SSR_ssn); else if (SSRType == SCP_LSS) rpackbytes(pptr, SCPMO_CNF_SSR_ssr_type, SSRType, SCPMS_CNF_SSR_ssr_type); rpackbytes(pptr, SCPMO_CNF_SSR_module_id, ModuleId, SCPMS_CONFIG_module_id); rpackbytes(pptr, SCPMO_CNF_SSR_mult_ind, 0x00, SCPMS_CNF_SSR_mult_ind); rpackbytes(pptr, SCPMO_CNF_SSR_ssn, SSN, SCPMS_CNF_SSR_ssn); rpackbytes(pptr, SCPMO_CNF_SSR_ssr_flags, 0x0, SCPMS_CNF_SSR_ssr_flags); if (GCT_send(m->hdr.dst, (HDR *)m)!= 0) printf("failed to send the SCCP_CONFIG SUBSYSTEM msg.\n"); relm((hdr *)m); WaitUntil(ModuleId, cmd & ANSWER_MASK); WaitUntil(ModuleId, NULL); 127

128 Anexo H. Procedimiento SCCPConfig 128

129 Anexo I. Procedimiento ProcessSCCPMsgReceive void ProcessSCCPMsgReceive(HDR* hdr, CApolloView* view) CApolloDoc* doc = view->getdocument(); CApolloDoc* doc_win = doc; u8 CompTypeIdentifier[1]; u8 TransId[MAX_TRANS_ID]; u8 ErrorCode[MAX_ERROR_CODE]; u8 CorId[1]; u8 OpeSpecifier[1]; u8 UserData[MAX_STRING]; u8 CallingAddr[MAX_CALLING_ADDR + 1]; int nlenuserdata; int nindex; BOOL bfound; nlenuserdata = ProcessMsg(hdr, UserData, TransId, ErrorCode, CorId, OpeSpecifier, CompTypeIdentifier, CallingAddr); if (CompTypeIdentifier[0] == INVOKE) // We receive an INVOKE message // This message is used by WIN module only if (OpeSpecifier[0] == OCANOT) // WIN Message bfound = false; for (nindex = 0; nindex < doc_win->m_uconnectionqueuelen &&!bfound; nindex++) if (doc_win->m_ptrsybaseconnection[nindex].nstatus == 0) bfound = true; doc_win->m_ptrsybaseconnection[nindex].nstatus = 1; ProcessOCANOTMsg(nLenUserData, TransId, CorId, view, doc_win, nindex, UserData); doc_win->m_ptrsybaseconnection[nindex].nstatus = 0; else if (OpeSpecifier[0] == SMSDPP) BYTE* ulocaltransid; BYTE* ulocalcorid; BYTE* ulocalcallingaddr; BYTE* ulocaluserdata; SMS_THREAD_NOTIFICATION* params; params = new SMS_THREAD_NOTIFICATION; ulocaltransid = new BYTE[MAX_TRANS_ID]; ulocalcorid = new BYTE[1]; ulocalcallingaddr = new BYTE[MAX_CALLING_ADDR + 1]; ulocaluserdata = new BYTE[nLenUserData]; memcpy(ulocaltransid, TransId, MAX_TRANS_ID); memcpy(ulocalcorid, CorId, 1); memcpy(ulocalcallingaddr, CallingAddr, MAX_CALLING_ADDR + 1); memcpy(ulocaluserdata, UserData, nlenuserdata); params->nlenuserdata = nlenuserdata; params->utransid = (LPBYTE)uLocalTransId; params->ucorid = (LPBYTE)uLocalCorId; params->uuserdata = (LPBYTE)uLocalUserData; params->ucallingaddr = (LPBYTE)uLocalCallingAddr; params->view = view; 129

130 params->doc = doc; if (AfxBeginThread(ThreadSMSMobileOriginated, params) == NULL) delete [MAX_TRANS_ID] ulocaltransid; delete [1] ulocalcorid; delete [nlenuserdata] ulocaluserdata; delete [MAX_CALLING_ADDR + 1] ulocalcallingaddr; // AfxMessageBox("Problems generating SMS Notification Thread"); DisplayLog("Problems generating SMS Notification Thread\n", view- >GetDocument()); delete params; else if (CompTypeIdentifier[0] == RETURN_RESULT) // We receive a Return Result message // This message is used by SMS module only ProcessReturnResultMsg(nLenUserData, TransId, CorId, view, doc, UserData); else if (CompTypeIdentifier[0] == RETURN_ERROR) // We receive a Return Error message // This message is used by SMS module only ProcessReturnErrorMsg(nLenUserData, TransId, CorId, view, doc, UserData); else if (CompTypeIdentifier[0] == RETURN_REJECT) // We receive a Return Reject message // This message is used by SMS module only ProcessReturnRejectMsg(nLenUserData, TransId, CorId, view, doc, UserData); 130

131 Anexo J. Subsistema de Configuración El subsistema de configuración para el módulo SCP es ejecutado por la tarjeta Datakinetis a partir de los archivos de configuración CONFIG y SYSTEM a partir de ellos el modulo ejecuta una rutina de configuración e inicialización de la interfaz, a través del procedimiento GC_LOAD. La figura muestra la arquitectura del modulo. Dentro del módulo SCP esta aplicación es llamada al iniciar el servidor y se mantiene en background durante todo el tiempo que el servicio este activo. 131

132 Anexo K. Procedimiento ThreadSCCPMsgReceive UINT ThreadSCCPMsgReceive(LPVOID lpparam) // We convert parameter to structure used THREAD_PARAMS* params = (THREAD_PARAMS *)lpparam; // Call original procedure ProcessSCCPMsgReceive(params->h, params->view); delete params; return 0; 132

133 Anexo L. Procedimiento ProcessMsg int ProcessMsg(HDR *hdr, u8 *UserData, u8 *TransId, u8 *ErrorCode, u8 *CorId, u8 *OpeSpecifier, u8 *CompTypeIdentifier, u8 *CallingAddr) // HDR: Message received // UserData: Structure to store TCAP parameter part of the message // TransId : Structure to store Transaction ID of the message // ErrorCode: Structure to store Error Code values (if present) of the message // CodId: Structure to store Correlation ID of the message // OpeSpecifier: Structure to store Operation Specifier of the message // CompTypeIdentifier : Structure to store Component Type Identifier of the message // Whole function returns length of TCAP parameter part of the message int nlenuserdata; nlenuserdata = SCCPDecode((_MSG *)hdr, UserData, CallingAddr); nlenuserdata = TCAPDecode(nLenUserData, UserData, TransId, ErrorCode, CorId, OpeSpecifier, CompTypeIdentifier); return(nlenuserdata); 133

134 ANEXO M. Mensajes PCCS3 Mensaje de configuración del módulo SCCP Este Mensaje es usado para configurar la parte SCCP de la interfaz PCCS6. 134

135 Mensaje de configuración de contadores 135

136 Configuración de subsistemas A través de este mensaje se configuran todos los subsistemas a los que tendra acceso el sistema. 136

137 Mensaje de remoción de subsistemas Para los casos en los que se requiere eliminar temporalmente subsistemas se envía este mensaje. Los parámetros usados para cada tipo de recurso son: 137

138 Mensaje de configuración de recursos asignados a subsistemas pertenecientes a puntos de señalización remotos. 138

139 Este mensaje es utilizado para transmitir Mensajes desde la Capa de SCCP hacia la Capa MTP. Las primitivas que soporta son: 139

140 Mensaje que indica la recepción de mensajes hacia la capa SCCP. El formato de las primitivas soportadas por este mensaje es el siguiente: 140

141 Mensaje de remoción de recursos en puntos de señalización remotos. 141

142 Mensaje indicador de cambio de estado de subsistemas Este mensaje se envía para identificar el cambio de estado de un subsistema, durante la fase de concesión o denegación de acceso. 142

143 Mensaje de Manejo de los subsistemas propios: 143

144 Mensaje de monitoreo de estadísticas de SCCP 144

145 Mensaje para la lectura de los datos almacenados en el Buffer y de la capacidad utilizada. 145

146 Mensaje de identificación de tareas distribuidas con el mismo SPC. Mensaje de Configuración Board Configuration Request Este Mensaje es enviado a la tarjeta una vez se inicia la carga de software, configura todos los módulos de la tarjeta. Contiene los signalling point codes para este signalling point y los adjacent signalling point(s), flags para permitir varios nivles level 1, level 2 and level 3 opciones de ejecución que se deben seleccionar y los parámetros físicos del link. 146

147 147

148 MTP Route Configuration Request Se utiliza este mensaje para agregar rutas a las tablas de enrutamiento de MTP. La definición de cada ruta se realiza a partir de un destination point code y de un linkset_id. Configure Clock Request Este mensaje se utiliza para configurar el reloj de la interfaz. 148

149 Los parámetros principales son: SC_SPEED CLK_MODE 149

150 Mensaje de Activación de link, MTP Link Activation Request Este mensaje es utilizado de acuerdo a los procedimientos recomendados por la ITU-T en la norma Q.704. El mensaje de confirmación indica que fue exitoso a través de un estado 0, esto implica que la solicitud fue recibida satisfactoriamente por la capa MTP3 y que el proceso de activación inicio. Paralelo a este existe el mensaje de desactivación. 150

151 Mensaje de empaquetamiento de MSU MTP Transfer Request A través de este mensaje se envía n las MSU proveniente de las capas superiores hacia la red de señalización. Paralelo a este tenemos el mensaje que recibe los paquetes desde la red de señalización y los envía a las capas superiores. 151

152 MTP Pause Indication 152

153 MTP Resume Indication MTP Status Indication 153

154 Board Status Indication MTP2 Level 2 State Indication El campo de Status tiene los siguientes posibles valores: 154

155 MTP2 Q.791 Event Indication El parámetro EVENT CODE tiene los siguientes valores: MTP3 Q.791 Event Indication 155

156 Las definiciones del EVENT CODE son: 156