diseño de un sistema para el monitoreo de la señalización no...traen consigo los sistemas de...
TRANSCRIPT
Instituto Superior Politécnico José Antonio Echeverría
CUJAE
DISEÑO DE UN SISTEMAPARA EL MONITOREO DE LA
SEÑALIZACIÓN NO.7
Sadiel de la Fé Siverio
La Habana, 2012
Tesis de Maestría
Página Legal
Diseño de un sistema para el monitoreo de la señalización No.7. – La Habana : InstitutoSuperior Politécnico José Antonio Echeverría (CUJAE), 2012. – Tesis (Maestría).
Dewey: 621.3 INGENIERIA ELECTRICA. ELECTRONICA.Registro No.: Maestria1140 CUJAE.
(cc) Sadiel de la Fé Siverio, 2012.Licencia: Creative Commons de tipo Reconocimiento, Sin Obra Derivada.En acceso perpetuo: http://www.e-libro.com/titulos
INSTITUTO SUPERIOR POLITÉCNICO “JOSÉ A. ECHEVERRÍA”
Facultad de Ingeniería Eléctrica
Departamento de Automática y Computación
Diseño de un sistema para el monitoreo de la señalización no.7
Tesis en opción al grado académico de Master en Ciencias
Autor: Ing. Sadiel de la Fé Siverio
Tutor: Dr. Ing. René Yáñez de la Rivera
La Habana, septiembre de 2011
A mi madre y mi padre,
A quienes luchan por un mundo mejor.
Agradecimientos Deseo agradecer a mi familia por su apoyo, comprensión y confianza de siempre; a mi tutor René
Yañez por su tiempo y su disposición; y de manera general a todo el que ha puesto su grano de
arena para la culminación de este trabajo.
Especialmente deseo agradecer al colectivo de profesores de la Maestría en Sistemas Digitales,
quienes me han permitido llegar hasta aquí, y de manera particular al profesor Alejandro Cabrera
por su invaluable ayuda.
Tabla de contenidos
_______________________________________________________________________Diseño de un sistema para el monitoreo de la señalización no.7
Tabla de contenidos
Resumen ...........................................................................................................................................7Introducción......................................................................................................................................8Capítulo I. Fraude y monitoreo en la red telefónica....................................................................13
Introducción ................................................................................................................................... 13 I.1 Fraude en las telecomunicaciones............................................................................................. 13 I.2 Características generales de los sistemas antifraude................................................................. 15
I.2.1 Riesgos en el monitoreo de la red...................................................................................... 18 I.3 Sistema de señalización no.7 .................................................................................................... 19
I.3.1 Estructura y funciones del protocolo SS7 .......................................................................... 19 I.3.2 Estructura del mensaje de señalización............................................................................. 21
I.4 Sondas para monitoreo de la red............................................................................................... 28 I.4.1 Sonda de la RAD. Estructura y funcionamiento ................................................................ 28 I.4.2 Sonda NSTS. Breve descripción......................................................................................... 31 I.4.3 Sondas IP ........................................................................................................................... 33 I.4.4 Valoraciones sobre las sondas descritas ........................................................................... 36
Conclusiones .................................................................................................................................. 37 Capítulo II. Tecnología y diseño del sistema de monitoreo .......................................................38
Introducción ................................................................................................................................... 38 II.1 FPGA de Xilinx. Generalidades .............................................................................................. 38
II.1.1 Detalles de la estructura de un FPGA.............................................................................. 38 II.1.2 Desarrollo de sistemas con FPGA ................................................................................... 39 II.1.3 Procesador MicroBlaze .................................................................................................... 41 II.1.4 Desarrollo de sistemas basados en microprocesadores................................................... 42
II.2 Diseño del sistema ................................................................................................................... 43 II.2.1 Requerimientos ................................................................................................................. 43 II.2.2 Etapa de desarrollo del sistema (fase 1) .......................................................................... 45
Capítulo III. Comprobación de resultados ...................................................................................69
Introducción ................................................................................................................................... 69 III.1 Simulación de la etapa de adquisición de datos ..................................................................... 69 III.2 Comprobación de la etapa de procesamiento de datos........................................................... 74 III.3 Comprobación de la etapa de transmisión de datos ............................................................... 78
Conclusiones..................................................................................................................................80Recomendaciones..........................................................................................................................81Bibliografía......................................................................................................................................82Otras webs consultadas ................................................................................................................83Anexo 1 ...........................................................................................................................................84Anexo 2 ...........................................................................................................................................85Anexo 3 ...........................................................................................................................................86Anexo 4 ...........................................................................................................................................87Anexo 5 ...........................................................................................................................................88
Tabla de contenidos
Diseño de un sistema para el monitoreo de la señalización no.7
Anexo 6 ...........................................................................................................................................89Anexo 7 ...........................................................................................................................................91Anexo 8 ...........................................................................................................................................92Anexo 9 ...........................................................................................................................................94
�
Resumen
Diseño de un sistema para el monitoreo de la señalización no.7 7
Resumen
El fenómeno del fraude causa grandes pérdidas a las operadoras de telecomunicaciones por
concepto del uso inapropiado de sus servicios. Además, se emplea para el robo, alteración o
destrucción de información valiosa; así como para enmascarar comunicaciones con fines ilegales y
subversivos, al margen del control gubernamental.
Los sistemas antifraude foráneos son muy costosos, además de implicar altos riesgos de
seguridad para nuestras redes, sin embargo, se utilizan en nuestro país.
No existe hoy un equipo desarrollado en Cuba capaz de procesar los mensajes de señalización no.
7, con el fin de servir de fuente de datos en tiempo real para el control del fraude. Por esta razón
se emplean equipos extranjeros como parte del sistema antifraude.
El sistema desarrollado es capaz de tomar de un flujo de datos los mensajes que se intercambian
entre varias centrales telefónicas a través de sus enlaces de señalización, seleccionar los
mensajes relativos a los procesos de inicio y liberación de llamadas; y enviarlos a un servidor. En
este servidor se conforma una base de datos con las trazas de las llamadas realizadas entre las
centrales monitoreadas, incluyendo las llamadas en curso.
Introducción
Diseño de un sistema para el monitoreo de la señalización no.7 8
Introducción
La importancia del sector de las telecomunicaciones lo hace ser estratégico. Engloba los diversos
canales por donde se transmite información y mueve en torno a sí grandes recursos económicos.
Por esta razón se requiere de una tecnología puntera. No obstante, la tecnología, aun con sus
complejidades y su continuo desarrollo, tiene debilidades que suelen ser explotadas.
Si a lo anterior se suma el despliegue de las tecnologías de la información (TI) en muchos de los
aspectos de la vida cotidiana y la ubicuidad del acceso a estas tecnologías, entonces el escenario
de un delito en este campo se hace muy complejo. La identificación del defraudador, por ende,
también resulta compleja.
El fraude es la vía empleada por no pocos individuos, y organizaciones inclusive, para obtener
fuertes sumas de dinero o evitar el pago de los servicios. Según un estudio publicado en junio de
2009 por Communications Fraud Control Association (CFCA, siglas en inglés), se estima que entre
los años 2005 y 2008 el fraude creció en un 34%. Esto significa pérdidas entre 72 y 80 billones de
dólares, lo cual se corresponde aproximadamente con el 4.5% de los ingresos del sector [1].
El delito sobre las TI también puede ser empleado por terroristas, redes de narcotráfico y
organizaciones criminales de cualquier tipo para garantizar el anonimato en sus comunicaciones.
En este aspecto nuestro país ha sido víctima de intentos de fraude de bypass (ver página 14) con
el objetivo de implementar redes de datos y voz fuera del control del gobierno y las empresas
proveedoras de servicio de Internet, con fines subversivos.
Producto de la convergencia de servicios de telecomunicaciones sobre las redes de datos,
muchas de las modalidades de fraude se concentran sobre estas redes. La suplantación o robo de
identidad, ataques de denegación de servicios (DoS) contra servidores corporativos, secuestro de
páginas web, robo de información sensible, alteración o eliminación de información y robo de
contraseñas, entre otros, son ejemplos de fraude en la red. Nótese que mediante algunas de estas
técnicas el defraudador puede hacerse con el control de números de tarjetas de crédito, cuentas
bancarias, plataformas de pago e incluso cuentas de juegos online [2] [3] [4].
Las pizarras telefónicas modernas (PABX) también son atacadas, resultando grandes pérdidas en
lo económico y en el funcionamiento de la empresa. En nuestro país se han registrado casos
donde la afectación económica supera los 80 mil dólares por concepto de llamadas internacionales
(no se menciona la fuente por ser información privada de ETECSA). Este tipo de fraude en
particular es de los más realizados, según la CFCA.
Introducción
Diseño de un sistema para el monitoreo de la señalización no.7 9
Pero esta problemática no solo afecta a las grandes redes de datos o al sector empresarial. Los
usuarios particulares de cualquier servicio de telecomunicaciones también son víctimas
potenciales. El fraude conocido como Premium Rate Service (ver página 14) afecta a numerosos
usuarios de telefonía fija y móvil. Esta modalidad es también una de las más difundidas según la
CFCA.
De lo anterior se puede definir el fraude como el acceso no autorizado a los sistemas o servicios
de telecomunicaciones con fines de lucro, enmascaramiento, o para lograr mayores privilegios
sobre los recursos de la red.
Para minimizar las consecuencias del fraude, además de los propios recursos de seguridad que
traen consigo los sistemas de comunicaciones, existen los sistemas de control de fraude (FMS,
siglas en inglés) y sistemas contra intrusos (IDS, siglas en inglés). Estos sistemas, están
destinados a prevenir, detectar y cortar acciones de fraude. Si bien no pueden asumir la
responsabilidad de controlar el 100% de esta actividad en las redes, garantizan un elevado índice
de eficiencia. El uso de estos sistemas de seguridad minimiza en gran medida las pérdidas
económicas a las operadoras; por lo cual se invierten grandes sumas en su adquisición.
Sin embargo, estas soluciones generalmente incorporan equipos para el monitoreo de las redes,
interceptando los enlaces de voz y datos. Al ser de factura extranjera, con tecnología propietaria,
los detalles del diseño y la programación son desconocidos y no revelados por el fabricante. De
manera que solo se logra conocer lo que el vendedor dice que hace y poco más. Estos equipos,
por sus características, son ideales para implementar “puertas traseras”, por donde puede
desviarse información, re-configurarse para determinados objetivos especiales y provocar fallas de
funcionamiento temporales o definitivas. Por otra parte, el soporte técnico especializado corre a
manos de especialistas extranjeros. Todo esto hace que este equipamiento sea ideal para el
espionaje electrónico.
Lo anterior es una razón más que indica lo apremiante de la necesidad de contar con nuestros
propios sistemas. El factor económico es importante, pero tanto o más lo es la seguridad de
nuestras redes y de la información que transportan.
Luego, el trabajo que se propone a continuación pretende contribuir a garantizar la seguridad de
nuestras redes y servicios de telecomunicaciones. Este trabajo debe sentar las bases para el
diseño de un equipo de mayores prestaciones capaz de sustituir una sonda para señalización no. 7
(SS7) del sistema antifraude instalado en ETECSA (Empresa de Telecomunicaciones de Cuba).
Introducción
Diseño de un sistema para el monitoreo de la señalización no.7 10
Para la realización de este trabajo se ha determinado la siguiente Situación problémica:
“Combatir el fraude en las telecomunicaciones sería menos costoso y más seguro para el país, si
se contara con un sistema antifraude de factura nacional. El sistema actualmente instalado no solo
requirió de una gran inversión, sino que sigue costando cifras elevadas por concepto de soporte
técnico. Además, los equipos desplegados en las centrales telefónicas representan un riesgo
potencial para la seguridad de nuestras redes”
Definimos entonces como el Problema a resolver, el hecho de que “En el país no se cuenta con el
equipamiento necesario para garantizar un sistema antifraude totalmente cubano que cumpla con
la calidad requerida, así como con los requerimientos que impone la seguridad de los servicios y
las redes de telecomunicaciones”
Dentro del conjunto de equipos que conforman la plataforma hardware de un sistema antifraude se
encuentran las sondas de señalización y de voz, concentradores de flujos, conmutadores
(switches), enrutadores y servidores de aplicación y bases de datos. Dentro de este universo
definimos como nuestro Objeto de Estudio “la sonda de señalización”.
El Objetivo general que se persigue con este trabajo es “Diseñar un sistema para el monitoreo de
la señalización no.7”.
Los Objetivos específicos propuestos para este trabajo son:
1. Capturar un flujo de datos de 2 Mbps e interpretar los mensajes de la SS7 contenidos en sus
tramas
2. Procesar los mensajes de la SS7 relativos a las llamadas en curso para conformar las trazas
que se enviarán al servidor
3. Transmitir a un servidor, vía Ethernet, las trazas de las llamadas con las cuales se
conformarán los registros de detalle de llamadas (CDR) que se guardarán en una base de
datos posteriormente
Para cumplir con los objetivos propuestos se han definido un conjunto de Tareas, recogidas
además en un cronograma de ejecución para este proyecto.
1. Análisis del estado del arte de los sistemas antifraude (incluye estudio de las sondas SS7)
2. Diseño, programación y simulación del módulo de adquisición de datos del flujo de 2 Mbps
3. Diseño, programación y comprobación del módulo de procesamiento de mensajes
4. Diseño, programación y comprobación del módulo de transmisión de datos vía Ethernet
Introducción
Diseño de un sistema para el monitoreo de la señalización no.7 11
5. Integración de los módulos y comprobación del sistema mediante la generación de mensajes
de señalización
Hoy tenemos acceso a algunas de las más avanzadas tecnologías de diseño digital. Esto, unido al
conocimiento acumulado y a la disponibilidad de información científico técnica, sobre todo en
Internet, hace que podamos plantearnos como Hipótesis lo siguiente: “Haciendo uso de la
documentación y las herramientas de diseño digital avanzado necesarias, es posible desarrollar,
en nuestro escenario cubano, un sistema capaz de resolver el problema de la adquisición y
procesamiento de los mensajes de señalización no. 7, con una alta eficacia y un coste
significativamente menor que sus equivalentes en el mercado internacional”.
Los Métodos de trabajo que se emplearán en el transcurso de este proyecto serán los siguientes:
Métodos de investigación teóricos: Permitirán analizar, sintetizar y comprender en
profundidad la información recopilada relativa a los sistemas antifraude y fundamentalmente
las sondas SS7.
Métodos de investigación valorativos: Permitirán establecer una comparación
fundamentalmente entre las diferentes tecnologías y características de las sondas. De igual
manera permitirán evaluar y seleccionar los componentes a utilizar y la estrategia para el
diseño del prototipo
Métodos de investigación experimentales: Fundamentalmente ayudarán a validar la hipótesis
planteada. Permitirán verificar de manera objetiva que la información contenida en la
señalización SS7 puede capturarse interviniendo un flujo de datos de 2 Mbps. Además
demostrarán que los datos necesarios para conformar los CDR pueden ser recibidos en una
computadora.
La factibilidad de la investigación se garantiza en un alto grado ya que se emplearán recursos
materiales reutilizables. Fundamentalmente se utilizará una tarjeta de evaluación de un FPGA
Spartan 3 (ver pág. 38) con un valor de menos de 200 USD; así como la herramienta de desarrollo
Xilinx Platform Studio. Se invertirán 15 meses de trabajo del autor para la culminación del
proyecto. En cualquier caso este trabajo aportará un conocimiento y experiencia significativos para
futuros proyectos similares; y sobre todo destaca el hecho de que un resultado favorable puede
conducir a la sustitución de un equipo de comunicaciones de un alto coste en el mercado
internacional por uno similar con tecnología propia.
Introducción
Diseño de un sistema para el monitoreo de la señalización no.7 12
El trabajo se compone de una introducción, tres capítulos de contenido específico, conclusiones,
recomendaciones, bibliografía y anexos.
En el capítulo primero se caracterizan de manera general los sistemas antifraudes, sus objetivos,
alcance y fuentes de información. Se brinda una panorámica del sistema de señalización no.7.
Finalmente se describen algunas de las sondas respecto a principio de funcionamiento, modos de
interconexión en la red, riesgos para la seguridad y diferentes tecnologías de fabricación.
El capítulo segundo aborda algunas características de los FPGA y la tarjeta de evaluación
empleada en el diseño. No obstante, lo fundamental de este capítulo es el diseño del sistema en
sí. Se describe la estructuración y programación de sus módulos.
El tercer capítulo se centra en mostrar los resultados de la comprobación e integración de los
componentes del sistema.
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 13
Capítulo I. Fraude y monitoreo en la red telefónica
Introducción
El panorama actual de las telecomunicaciones exhibe un ritmo de incremento vertiginoso en todos
los sentidos, fundamentalmente el tecnológico. Las nuevas tendencias de diseño digital,
acompañadas de los avances científico-técnicos en el ámbito de las transmisiones de señales, han
logrado desarrollar infraestructuras y sistemas de comunicaciones cada vez más orientados a
cubrir las crecientes necesidades de la sociedad. Las comunicaciones móviles, por ejemplo, han
ganado un espacio importante, multiplicando el acceso a las redes de datos desde su introducción
en el mercado. Por otra parte las Redes de Próxima Generación (NGN) se expanden integrando
servicios de telecomunicaciones casi imprescindibles ya en una sociedad informatizada.
En este ámbito, garantizar la seguridad de sistemas y servicios se hace vital para las operadoras
de comunicaciones y para los propios usuarios.
Este capítulo aborda algunas cuestiones relativas al fraude sobre las redes de telecomunicaciones,
así como aspectos sobre el monitoreo que se realiza sobre estas redes.
I.1 Fraude en las telecomunicaciones
Las operadoras centran sus esfuerzos en lograr cada vez mayores ingresos y mejorar el
desempeño de sus redes y sistemas. Para ello intentan captar cada vez una mayor cantidad de
clientes. La satisfacción del cliente, entre otros aspectos, está determinada por la disponibilidad y
confiabilidad que le brinden los servicios a los que está suscrito. El fraude contribuye de manera
muy negativa a este propósito.
ETECSA, como operadora de telecomunicaciones de Cuba no está exenta de este mal. Cada año
las pérdidas de ETECSA se valoran en miles de dólares a causa de la actividad de fraude. Por
citar un ejemplo; un estudio realizado en 2007 por el autor, en la Gerencia Antifraude de ETECSA,
determinó una afectación económica en un mes de 30 mil USD por concepto de llamadas ilegales
desde teléfonos públicos.
Los métodos para cometer fraude y los mismos defraudadores han evolucionado
considerablemente al ritmo del avance de las tecnologías. El fraude puede ser cometido por
elementos ajenos a las operadoras de comunicaciones o por personal interno. Estos últimos son
los que más daño pueden ocasionar, en tanto tienen conocimiento de los sistemas y en ocasiones
incluso, conocen los métodos y técnicas de detección.
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 14
El fraude tiene como principal objetivo el lucro. Los defraudadores, por concepto de re-venta de
servicios (por los que ellos no pagan) pueden ganar altas sumas de dinero. Además existen otras
razones para cometer fraude, como son el ocultamiento de la identidad y el establecer
comunicaciones fuera del control legal o gubernamental. Esto puede ser empleado por sujetos u
organizaciones dedicadas al terrorismo, espionaje y otro tipo de actividades ilegales.
Entre los tipos de fraude conocidos se encuentran:
Fraude de suscripción: Es aquel donde un supuesto cliente contrata líneas telefónicas
utilizando identificación falsa. De esta manera no es posible su localización para efectuar el
cobro por los servicios.
Bypass: Con esta modalidad se establecen llamadas a terminales telefónicos burlando el
sistema de facturación de la operadora. Generalmente usan servicios de voz sobre IP
(VoIP) o comunicaciones satelitales para establecer los enlaces.
Premium Rate Service (PRS): Son números telefónicos que generan ganancias a su
suscriptor proporcionales a la cantidad de llamadas que reciben. Existen aplicaciones
llamadas dialers que se pueden comportar como un programa maligno y realizan llamadas
automáticas desde computadoras, a través de un MODEM, hacia número PRS
Clonación: Existe fundamentalmente en servicios de telefonía móvil y pública. En la
telefonía móvil es posible duplicar una tarjeta telefónica. La nueva tarjeta funciona en un
nuevo terminal que cursa tráfico de llamadas y mensajería que paga el cliente original. En
el caso de la telefonía pública es posible clonar las tarjetas chips prepagadas con
dispositivos electrónicos programables que responden al intercambio de señales con el
equipo telefónico, como si fuesen tarjetas legítimas.
Desvío de líneas (en inglés, clip on): Consiste en conectar un terminal en paralelo sobre
una línea telefónica ajena y ejecutar llamadas (fundamentalmente internacionales) que
posteriormente se facturarán al propietario legítimo del servicio telefónico.
Fraude de PABX: Esta modalidad consiste en acceder de manera no autorizada a los
recursos de una PABX. Una vez obtenidos los permisos necesarios, el atacante es capaz
de escuchar mensajes de voz de los usuarios, apropiarse de los buzones de voz para su
propio uso, efectuar llamadas de manera remota, etc.
Fraude sobre teléfonos públicos: Aprovechando las muchas vulnerabilidades que puede
tener un terminal de telefonía pública, un defraudador puede efectuar llamadas
gratuitamente. Entre las vulnerabilidades se pueden encontrar fallos ante variaciones de
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 15
voltaje en la línea, no autenticación del equipo terminal (permite hacer clip on sobre una
línea dedicada a un teléfono público) y las tarjetas chips clonadas mencionadas antes, por
ejemplo [5].
Dado el creciente desarrollo y la iniciativa de los defraudadores, los especialistas de control de
fraude están obligados a alcanzar un nivel profesional elevado. Los medios técnicos también
deben estar en continuo desarrollo e implementar medidas de seguridad preventivas y correctivas
que contrarresten las vulnerabilidades de los sistemas de comunicaciones.
I.2 Características generales de los sistemas antifraude
Un sistema antifraude tiene como objetivos la prevención, detección y corte oportunos de
actividades sospechosas de fraude. Estos sistemas se componen de manera general por una
plataforma software y una plataforma basada en equipos distribuidos por la red. Entre ellos se
encuentran sondas de voz y de señalización, concentradores de flujo, módulos para bloqueo de
llamadas (en dependencia de la tecnología empleada) y equipos de interconexión de redes
Ethernet.
Las sondas monitorean la señalización y la voz entre centrales telefónicas. Para esto, los
concentradores de flujo previamente muestrean los enlaces inter-centrales y combinan en una
trama digital de salida hasta 31 canales de datos, de los contenidos en los enlaces de señalización
y voz. La cantidad de enlaces que soporta a la entrada un concentrador varía según el fabricante.
Esta trama se envía para ser analizada por la sonda.
Dos centrales telefónicas están interconectadas mediante varios enlaces del tipo E1. Estos
enlaces operan a una velocidad de 2 Mbps y cuentan con un canal de sincronismo (canal cero) y
31 canales de datos, cada uno de 8 bits.
Fig. I.1 Diagrama de la trama digital E1
La duración de la trama (125us) se corresponde con el período de muestreo de la señal telefónica,
cuya frecuencia de muestreo por Ley de Nyquist es de 8 KHz. El tiempo de bit es de 488ns según
normativa de la UIT (Unión Internacional de Telecomunicaciones). De ahí que resulten 32 canales
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 16
multiplexados de 8 bits con ventanas de tiempo de 3.9us por octeto. Suele llamársele a los canales
time slot. Los time slot portan muestras de voz de las llamadas telefónicas o mensajes de
señalización, según se hayan configurado en la central telefónica. La codificación de línea
empleada en los enlaces entre centrales es HDB3 [6].
El primer octeto de la trama E1 se utiliza para el alineamiento de trama. En el capítulo 2, cuando
se describa el módulo de adquisición de datos del sistema diseñado se detallará este mecanismo.
Todos los enlaces que comparten las centrales telefónicas poseen mecanismos de sincronización,
de manera que en un estado de funcionamiento estable, no debe haber desfase entre los enlaces.
Los concentradores de flujo se conectan directamente al flujo de datos entre las centrales, y
generan su propia señal de reloj. Estos equipos, además de agrupar en una trama digital de salida
varios canales de datos (según configuración) de entre los enlaces tomados, generan una señal de
reloj de salida para sincronizar dicha trama. Como se mencionó antes, esta señal de salida porta
los datos que analiza la sonda posteriormente.
Fig. I.2 Conexión del concentrador de flujos en la red telefónica
La plataforma software está compuesta por varias aplicaciones corriendo en servidores con
funciones específicas dentro del sistema. También existen estaciones de trabajo con un módulo
“cliente” para el control manual del fraude. De manera general existe una aplicación servidor
encargada de gestionar la información que es tributada al sistema. Un primer módulo recibe los
datos directamente de fuentes externas, incluidas las sondas. Para el caso de los datos
provenientes de las sondas, este módulo se comporta como una interfaz de adquisición de datos
en tiempo real e interpreta los datos binarios recibidos y construye los CDR. En otro módulo se
interpretan los campos de la señalización según las características específicas de la red donde se
instale el sistema. Luego, los CDR pasan a un módulo de distribución, desde donde son enviados
al proceso que los almacena finalmente en la base de datos.
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 17
Una aplicación de uso obligatorio en cualquier sistema antifraude es un gestor de base de datos.
Diariamente se reciben en los servidores millones de trazas de llamadas. Una gran capacidad de
almacenamiento es indispensable para este tipo de sistemas. Luego, un gestor de BD debe contar
con suficiente espacio disponible para almacenar las trazas de llamadas.
Finalmente un motor de búsqueda es el que implementa una estrategia para detectar y alertar
sobre la posible ocurrencia de un fraude. Para ello los diferentes algoritmos que se emplean
utilizan la información contenida en la base de datos, así como los datos en tiempo real
provenientes de las sondas. También se usan bases de datos externas con información de los
departamentos de facturación y clientes mayoritariamente [7].
Al registro de detalle de llamadas se pueden añadir datos propios del sistema, como el
identificador de la sonda que capturó el mensaje SS7 y la fecha y hora de captura, por ejemplo.
Los campos más significativos de un CDR son:
Fecha/hora de inicio de llamada
Fecha/hora de fin de llamada
Duración de llamada
Categoría de llamada (nacional o internacional)
Nivel de prioridad del abonado
Categoría de abonado (particular, PABX, teléfono público, etc.)
OPC y DPC (puntos de origen y destino del mensaje SS7 respectivamente)
Los Sistemas Antifraude han transitado por varias generaciones. En un principio el proceso de
detección se realizaba mediante reglas y umbrales definidos por el administrador del sistema. Una
regla constituye una serie de parámetros de una o varias llamadas que se chequean, y que al
cumplirse generan una alerta. Por otra parte, los umbrales son límites definidos para determinados
parámetros relativos a las llamadas que cuando se sobrepasan también generan alertas. Un
ejemplo de esto puede ser que un abonado que realice 10 llamadas internacionales de más de 2
minutos en un mismo día. Si el umbral estaba definido para 9 llamadas de este tipo, este caso
particular generaría una alerta.
Luego se incorporan en una segunda generación, los perfiles de usuarios. Los perfiles describen
de manera cuantitativa el comportamiento de un usuario en cuanto al uso del servicio telefónico,
en diferentes contextos como días laborables, fines de semana, horario de la mañana, de la tarde
y de la noche. El sistema es capaz de “aprender” de cada usuario durante un tiempo determinado
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 18
y elaborar su perfil individual. Luego de este período de aprendizaje es capaz de detectar
variaciones notables en los perfiles y generar la alerta correspondiente [7].
La tercera generación de los Sistemas Antifraude usa una combinación de los métodos de
detección anteriores con otras técnicas novedosas. Se suman entonces la implementación de
redes neuronales para mejorar el aprendizaje de los sistemas, nuevos algoritmos estadísticos y
reconocimiento de patrones. Estos sistemas son capaces de actuar sobre comunicaciones de voz
y datos. Las técnicas de minería de datos también se incorporan en esta nueva generación de
Sistemas Antifraude; pues la búsqueda y correlación de información en bases de datos
voluminosas requiere de mecanismos eficientes [8].
Subex Azure Fraud Management System (SAFMS) es ejemplo de un sistema antifraude de tercera
generación de la firma SUBEX AZURE. Existen otros bien posicionados en el mercado mundial
como el de Hewlett Packard, el Watch Dog de la firma Basset Labs, el Fraud View de ECTEL,
Deffiant de procedencia italiana, entre otros.
I.2.1 Riesgos en el monitoreo de la red
No obstante, a pesar de la reconocida calidad de estos sistemas, su carácter intrusivo en las redes
los hace un peligro potencial, como antes se mencionó. Por el propósito específico de estos se
justifica tener en sus bases una gran cantidad de información; y además, el acceso a información
externa con datos de los usuarios, facturación, etc. Estos sistemas, basados en las características
de operación de las sondas y módulos hardware de bloqueo de llamadas, pueden ser capaces de
interferir las comunicaciones nacionales y con el exterior. La señal para ejecutar esto puede
enviarse en el DTMF (tono dual multi-frecuencia) de una llamada telefónica, por ejemplo. Además
de esto, es posible recopilar información sobre la estructura de la red conociendo identificadores
de nodos de señalización, OPC (código del punto de origen) de centrales telefónicas, cantidad de
circuitos y otros elementos.
Al tener acceso a las bases de clientes y facturación, un proceso oculto del sistema puede hacer
búsquedas de abonados específicos y realizar análisis de tráfico de determinados abonados de
interés. La información referente a los casos de fraude que estén en investigación se almacena
regularmente en las estaciones de trabajo donde reside una aplicación cliente del sistema. Esta
información, como toda la que se encuentre en la red del sistema, es de muy fácil acceso por
procesos ocultos que luego pueden enviarla a través de una sonda mediante la generación de una
llamada telefónica en un canal vacío o bien sustituyendo la voz por datos en determinadas
llamadas telefónicas. Por tanto, las medidas de seguridad para la instalación y explotación de
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 19
sistemas extranjeros deben ir más allá de la instalación en una red cerrada. La variante más
económica y segura es, sin dudas, la creación de un sistema antifraude cubano.
I.3 Sistema de señalización no.7
El sistema de señalización no.7 (SS7) garantiza, en una red telefónica, la gestión de los enlaces y
circuitos, el enrutamiento de las llamadas; y el proceso de establecimiento, mantenimiento y
liberación de estas fundamentalmente. SS7, frecuentemente llamado protocolo SS7 también,
realiza todas sus notificaciones cursando mensajes cuyos formatos y códigos están normados por
la UIT.
SS7 en nuestro país sigue un esquema de señalización por canal común. Esto significa que se
emplea un canal dedicado para el intercambio de los mensajes de gestión y establecimiento de
llamadas. O sea, entre los flujos E1 que enlazan a las centrales telefónicas para la transmisión de
señales de voz, se encuentra, al menos un canal exclusivo para el intercambio de mensajes.
Generalmente se hallan dos de estos canales operando en paralelo (nunca ambos en el mismo
flujo E1). Cada uno soporta una carga del 50% del volumen de mensajes de señalización, y
asumen el total de la carga cuando el otro presenta una avería.
En el caso de la Red Pública de Servicios Telefónicos (PSTN, siglas en inglés), SS7 cuenta con
Puntos de Señalización (SP, siglas en inglés). Estos SP se logran dotando a los nodos de
conmutación (centrales telefónicas) de la PSTN, de las funcionalidades necesarias para el manejo
de la señalización. Luego la red de señalización coexiste (en el esquema de canal común) con la
red de enlaces de voz.
I.3.1 Estructura y funciones del protocolo SS7
El protocolo de señalización no.7 posee una estructura de capas que cumple con el estándar del
modelo OSI, como muestra la figura I.3.
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 20
Fig. I.3 Analogía entre el modelo OSI y SS7.
La estructura del sistema SS7 se puede dividir desde el punto de vista funcional en una parte de
transferencia de mensajes (en inglés, MTP) y varias partes de usuario (en inglés, UP) diferentes.
Cada una de las UP se sirve de la capacidad de transporte que posee la MTP, cuya función
principal es por tanto, garantizar la transferencia de los mensajes desde y hacia los niveles
superiores de este protocolo.
Aunque los módulos hardware que intervienen en el intercambio de los mensajes de señalización
no se puedan separar por bloques en su estructura, sí es posible establecer un límite entre las
funciones de cada nivel del protocolo. Cada nivel del sistema de señalización tiene sus funciones
bien definidas.
MTP L1. Nivel físico
La capa física de SS7 establece las características eléctricas, físicas y funcionales del enlace de
datos de señalización. En la Rec. Q.702 de la UIT-T se norman estas características. Aquí se
establece, por ejemplo, que el enlace de datos ha de ser un trazado bidireccional, con dos canales
de datos que operen de conjunto y en sentido opuesto a una misma velocidad de transmisión.
También se plantea que los canales de transmisión digitales pueden derivarse de señales
multiplexadas con velocidades de 1544, 2048 ó 8448 Kbps [10] [12].
En nuestro país se emplea específicamente la señalización entre centrales telefónicas sobre
enlaces de 2 Mbps (2048 Kbps) con canales a 64 Kbps.
MTP L2. Nivel de enlace de datos
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 21
En la capa 2, donde se implementa el enlace de datos, se lleva a cabo un intercambio de
mensajes (unidades de señalización) con características similares al del protocolo HDLC (en
inglés, High Level Data Link Controller). Este último envía los datos en forma de mensajes
delimitados por una bandera de inicio e incluye un campo de corrección de errores de transmisión,
además de uno o dos octetos para el control de transmisión. En la capa 2 de SS7 se lleva a cabo
un grupo importante de funciones tales como:
� delimitación de las unidades de señalización
� alineación de las unidades de señalización
� detección de errores
� corrección de errores
� alineación inicial
� supervisión de errores en el enlace de señalización
� control de flujo
Cada una de las anteriores funciones está soportada por campos específicos que componen la
unidad de señalización. Más adelante se aborda la estructura del mensaje y su vinculación con
algunas de estas funciones [10] [13].
MTP L3. Nivel de red
El nivel 3 implementa dos grupos de funciones: Tratamiento de los mensajes de señalización y
Gestión de los enlaces de señalización.
Las funciones de tratamiento de los mensajes, transfieren la unidad de señalización hacia el
enlace de señalización o hacia la UP que corresponda. Esto implica que los mensajes enviados
desde una UP determinada en el punto de señalización transmisor deben llegar hasta la misma UP
en el punto de señalización receptor. De esto se encarga la función de distribución de mensajes.
El otro grupo de funciones se encarga de la gestión de la red de señalización. Estas funciones
garantizan el control del encaminamiento de los mensajes. Controlan y configuran las facilidades
de la red, resolviendo las fallas que puedan ocurrir para mantener estable la transferencia de
mensajes. Además se controla la congestión en la red [10] [14].
I.3.2 Estructura del mensaje de señalización
Todo el intercambio de información de señalización se realiza a través de mensajes. Cada
mensaje constituye una unidad de señalización. La unidad de señalización de mensaje (MSU) está
compuesta por un campo de información de señalización (SIF) de longitud variable, que porta los
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 22
datos de la parte de usuario; y además se compone de varios campos de longitud fija los cuales
intervienen en la transferencia del mensaje.
La longitud total de una unidad de señal no debe superar los 280 octetos. La transmisión de los
mensajes se realiza enviando el bit menos significativo primero y comenzando por el campo BSN
tras la bandera de inicio. Se finaliza con el campo de bits de verificación de errores, y puede
enviarse una bandera de cierre tras este campo.
Además de la MSU existen dos clases de unidades de señalización: la unidad de señalización del
estado del enlace (LSSU, siglas en inglés) y la unidad de señalización de relleno (FISU, siglas en
inglés). La unidad de señalización FISU se envía cada 72 ms insertada entre el flujo de banderas,
cuando no hay datos que transmitir a través del enlace.
El orden de transmisión de cada unidad de señalización es como se muestra en la figura I.4.
Dentro de cada campo se transmiten los bits comenzando por el menos significativo.
Cada MSU está formada por los siguientes campos.
� F: bandera
� BSN: número de secuencia hacia atrás
� BIB: bit indicador hacia atrás
� FSN: número de secuencia hacia adelante
� FIB: bit indicador hacia adelante
� LI: indicador de longitud del mensaje
� SIO: octeto de información de servicio
� SIF: información de señalización
� SF: campo de estado
� CK: bits de verificación
El campo SIF está compuesto a su vez por una etiqueta de encaminamiento con los códigos de
origen y destino del emisor y el receptor del mensaje (OPC y DPC respectivamente), y el
identificador del enlace de señalización (SLS).
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 23
Fig. I.4 Formato de las unidades de señalización
Bandera
La bandera es el campo que indica el comienzo o fin de un mensaje. Este campo se denota por el
valor constante ´01111110´.
Este valor de la bandera no se puede repetir en ninguno de los octetos del mensaje de
señalización. Por lo tanto, el punto transmisor garantiza “romper” cada cadena de seis unos
consecutivos en cada mensaje insertando un cero tras el quinto uno detectado. Este mecanismo
de transparencia solo se lleva a cabo después de transmitir la bandera. Luego, en el receptor, se
lleva a cabo el proceso inverso. Se elimina un cero tras cada cadena de cinco unos que se detecte
luego de recibir la bandera de inicio de mensaje.
La bandera es insertada en el mensaje en el nivel 2 de la MTP por el procedimiento de delimitación
de la unidad de señalización.
Indicador de longitud
Este campo indica la longitud (en octetos) del mensaje entre el propio campo LI y el campo CK.
Nótese en la figura 4 que para las FISU, el campo LI es cero. Para LSSU el indicador puede tomar
los valores 1 ó 2; en tanto para MSU puede llegar hasta 63. Se sobreentiende que un valor de 63
indica que entre los campos SIO y SIF de una MSU pueden existir hasta 272 octetos.
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 24
Información de servicio
Este campo se subdivide en indicador de servicio y campo de subservicio. El primero de ellos está
destinado a informar a qué parte de usuario corresponde el mensaje; y solo se emplea en las
MSU.
Cuando el campo indicador de servicio se codifica como 0101 significa que el mensaje
corresponde al nivel de Parte de Usuario del protocolo. El campo SIF se denomina mensaje ISUP
en este caso.
Números secuenciales e indicadores de bits (FSN, BSN, FIB, BIB)
A través de los números secuenciales y los indicadores de bits se garantiza el control de los
mensajes enviados. Este mecanismo se conoce como control básico de errores; y garantiza que
no haya inconsistencias en la secuencia de las unidades de señalización. Para esto implementa un
mecanismo eficaz de retransmisión ante fallos. Sobre estos campos se basa la operación de varias
funciones del nivel 2 de la MTP mencionadas anteriormente.
FSN es un número secuencial (entre 0 y 127) que se le asigna a un mensaje al ser transmitido. A
cada mensaje transmitido corresponde un acuse de recibo. La parte receptora de señalización
acusa el recibo de uno o varios mensajes con uno al que pone en su campo BSN (entre 0 y 127) el
número del último FSN recibido. O sea, con esto se indica al transmisor que el actual y los
mensajes previos fueron recibidos de manera ordenada.
El transmisor de unidades de señalización almacena todas las unidades enviadas hasta tanto las
mismas no sean reconocidas explícitamente por el receptor. Cuando el receptor no acusa recibo
de una o varias unidades el transmisor las reenvía.
Es indispensable para el reconocimiento positivo de una unidad de señalización que los campos
FIB y BIB sean iguales. Cuando se recibe una unidad con los campos FIB y BIB diferentes, todas
las unidades que almacena el transmisor para retransmisión serán enviadas nuevamente.
Entonces se cambia en cada una de las retransmitidas el FIB y se iguala al BIB. La referencia 7,
en su página 15 abunda sobre este mecanismo.
Bits de verificación
Luego de que en el receptor se eliminan los ceros insertados en el transmisor para transparencia,
se verifica que el mensaje tenga un número entero de octetos y que estos cuenten seis como
mínimo, contando la bandera de apertura. De no ser así, se descarta el mensaje.
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 25
Tras lo anterior, tiene lugar en el nivel 2 de la MTP una función de corrección de errores de
transmisión. Esta utiliza los 16 bits (CK) que anteceden a la bandera de cierre del mensaje o
apertura del próximo (según corresponda). Estos 16 bits son generados en el extremo transmisor.
Los 16 bits son el complemento a uno (´1´) de la suma módulo dos de:
� el resto de xk (x15 + x14 + x13 + x12 … + x2 + x + 1) dividido (módulo 2) por el polinomio
generador x16 + x12 + x5 + 1, siendo k el número de bits existentes en la unidad de
señalización sin incluir la bandera de apertura y los bits de control, excluidos además los
ceros insertados para transparencia; y
� el resto obtenido después de multiplicar por x16, y seguidamente dividir (módulo 2) por el
polinomio generador x16 + x12 + x5 + 1, el contenido de la unidad de señalización existente
entre (pero sin incluir), el último bit de la bandera de apertura y el primero de los bits de
control, excluidos los bits insertados para transparencia.
En el extremo receptor se realiza la comprobación de los bits de verificación y el resto del mensaje
para detectar errores de transmisión. Para esto se toman todos los bits protegidos (incluidos los 16
bits de verificación) y se dividen entre el polinomio generador. El resto de la división debe ser el
número ´0001110100001111´ si no hubo errores de transmisión. En caso contrario se descarta el
mensaje [13].
Información de señalización (para MSU)
El campo de información de señalización incluye datos que se utilizan tanto en el nivel 3 de la MTP
como en la Parte de Usuario (nivel 4), como se observa en la figura I.5.
Fig. I.5. Formato expandido del campo SIF
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 26
Los primeros 32 bits del SIF los ocupa la etiqueta de encaminamiento. Esta etiqueta permite
conocer los puntos de origen y destino del mensaje (OPC y DPC respectivamente), así como el
enlace de señalización asignado (SLS) en caso de que exista compartimiento de carga entre más
de un enlace. La etiqueta de encaminamiento es indispensable para el envío de un mensaje a un
punto de señalización en el nivel 3 de la MTP.
El CIC es un identificador de 8 bits con el que se denota el circuito de voz que se asignó a la
llamada.
El código de tipo de mensaje es un identificador para cada mensaje ISUP. Existen varios tipos de
mensajes para tipificar diversos eventos en la red (ver anexo 1). La estructura de cada mensaje
ISUP está formado por tres partes (ver anexo 2):
� Parte Fija Obligatoria
� Parte Variable Obligatoria
� Parte Opcional
Cada parte de un mensaje ISUP, a su vez, está formada por varios parámetros. Los parámetros
son unidades de información y para cada tipo de mensaje están normados los parámetros que
debe contener, la longitud en bits y el orden de transmisión de estos. Algunos de los parámetros
son el número llamador, número llamado, categoría del llamador, causa de terminación de la
llamada, número de reenvío, referencia de llamada, entre otros. La codificación de bits de cada
parámetro es el más bajo nivel donde aparece la información contenida en un mensaje de
señalización. En la referencia 11 (página 47 a la 55) se abunda sobre la estructura de los
parámetros a nivel de bits.
La Parte Fija Obligatoria está conformada por varios parámetros fijos y de longitud conocida. Cada
mensaje tiene su configuración particular. El primero de los parámetros obligatorios se ubica justo
después del código del tipo de mensaje en la unidad de señalización.
La Parte Variable Obligatoria está conformada por punteros, indicadores de longitud y parámetros.
Los punteros son números de 8 bits que indican la posición de comienzo de un parámetro. El valor
de un puntero es la cantidad de octetos que hay entre el comienzo de este y el primer bit del
parámetro correspondiente. Cada parámetro comienza con un indicador de longitud (un octeto). El
indicador de longitud contiene la cantidad de octetos del parámetro menos uno (no se cuenta a sí
mismo).
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 27
El último puntero dentro de la Parte Variable Obligatoria señala la ubicación del inicio de la Parte
Opcional. El valor de este puntero es la cantidad de octetos que existen entre él y la Parte
Opcional.
La Parte Opcional se compone de un nombre de parámetro, longitud del parámetro y el parámetro
mismo. El puntero que señala a esta parte, apunta al nombre del primer parámetro. A continuación
del nombre aparece el indicador de longitud del parámetro, el cual contiene la cantidad de octetos
de este (sin contar el propio indicador ni el nombre del parámetro). La misma estructura se repite
para los parámetros subsiguientes. El octeto ´00000000´ indica el fin de la Parte Opcional y del
campo SIF [11] [13].
Resumiendo, el campo SIF contiene justamente la información útil del mensaje de señalización.
Contiene el origen del mensaje, su destino, el enlace que lo transporta, el circuito de voz al que se
le asocia (en caso de mensaje de gestión de llamada), un identificador del tipo de mensaje y
parámetros que detallan en profundidad la notificación. El establecimiento de una llamada, por
ejemplo, comienza con un mensaje IAM (mensaje de dirección inicial) [14].
Un segmento del código binario del campo SIF para un mensaje IAM sería:
………….. 00000011 00001010 00000001 00100000 00000000 00000001 00010100 0001
00000000000010 00000000000001 (LSB, primer bit transmitido)
En la cadena anterior se relacionan, desde el LSB hacia atrás:
DPC (14 bits)
OPC (14 bits)
SLS (4 bits)
CIC (8 bits)
Tipo de mensaje “IAM” (8 bits)
Parámetro 1 obligatorio “Nature of connection indicators” (8 bits)
Parámetro 2 obligatorio “Forward call indicators” (16 bits)
Parámetro 3 obligatorio “Calling party`s category (8 bits)
Parámetro 4 obligatorio “Transmission medium requirement” (8 bits)
El conjunto de mensajes que se intercambian en el proceso de establecimiento y liberación de una
llamada se puede observar en el anexo 3.
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 28
I.4 Sondas para monitoreo de la red
La sonda es uno de los componente de mayor importancia dentro de un sistema antifraude. La
tarea fundamental de una sonda de señalización consiste en analizar todos los mensajes SS7 que
se intercambian entre centrales telefónicas, y enviar a un servidor los datos que sirven para
conformar un CDR.
Las sondas SS7 constituyen un equipamiento muy especializado, con un alto nivel de integración y
tecnología, y muy costoso. Solo determinadas firmas se dedican a comercializar este producto.
Algunas de ellas son la RAD (Israel), Cibertec (Costa Rica) y Tekno Telecom (EE.UU.). Las
sondas israelíes instaladas en nuestro país tienen un valor de más de 150 mil USD cada una [15]
[16] [17].
El nivel de información sobre las características de estos equipos es muy limitado, por lo que se
dificulta hacer un estudio a profundidad sobre su estructura y funcionamiento. La experiencia de
trabajo con sondas SS7 de la RAD ha permitido un mayor conocimiento sobre estas. Por lo tanto
este acápite abundará mayormente en las características de este equipamiento.
I.4.1 Sonda de la RAD. Estructura y funcionamiento
Este equipo está concebido para el análisis de los mensajes de señalización no.7. La captura de
los mensajes puede realizarse mediante una conexión directa a los enlaces entre las centrales
telefónicas (ver figura I.6). No obstante, una configuración más eficiente sería tomar como señal de
entrada un flujo E1 proveniente de un concentrador de flujos, donde cada canal porte solo
información de señalización (figura I.2). La sonda de la RAD permite además monitorear canales
de voz.
Fig. I.6 Conexión paralela de una Sonda SS7 entre centrales telefónicas
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 29
El equipo se divide en dos secciones. La sección superior o Sección de Interfaces está
conformada por las tarjetas de interfaces externas. La sección inferior o Sección de Análisis y
Procesamiento la componen las tarjetas de procesamiento de datos. Estas tarjetas se
interconectan a través de un bus PCI.
Para la adquisición de los datos de la red, cada sonda tiene una capacidad de conexión para 20
flujos E1, para lo cual pueden instalarse hasta 5 tarjetas de interfaces externas I/O OCDI con
capacidad de 4 flujos cada una. Las interfaces Ethernet con que cuenta la Sección de Interfaces
posibilita la comunicación de la Sonda con otros elementos del sistema. Las interfaces Ethernet se
ubican en las tarjetas I/O SSIG y I/O MCPU.
La tarjeta I/O OCDI es capaz de interpretar la codificación HDB3 y AMI. Esta interfaz cumple con la
Rec. G. 703 de la UIT-T, relativa a las características físicas y eléctricas de las señales a 2 Mbps.
Esta tarjeta, luego de capturar los datos de los flujos conectados, los envía a una tarjeta de
procesamiento OCDI, quien se encarga de evaluar el estado del E1 de entrada, verifica si existen
errores en la trama E1, y genera alarmas por pérdidas de señal o sincronismo. Además verifica el
canal muestreado y determina si es un canal de señalización o voz. Para esto debe estar
previamente configurada con el detalle de los canales que se usarán para voz y para señalización
dentro de un flujo E1 determinado. Si el canal muestreado es de voz, OCDI redirecciona los datos
hacia la tarjeta de procesamiento FDSP (ó FDSPE); en caso de ser un canal de señalización se
envían a la SSIG. El flujo de datos entre estas tarjetas se realiza a través del bus PCI del equipo.
SSIG es una tarjeta de la Sección de Análisis y Procesamiento. Está destinada a la interpretación
de los mensajes SS7. Esta tarjeta interpreta los mensajes de señalización y extrae los campos
necesarios para conformar un CDR. Una vez procesados los mensajes, envía los campos a la
interfaz I/O SSIG. Esta última es la encargada de transmitir la información al servidor de
aplicaciones. I/O SSIG emplea una interfaz Ethernet para la transmisión de los pre-CDR hacia el
servidor; utiliza el protocolo TCP/IP para el envío de los datos.
Esta sonda permite el muestreo de canales de voz, como se mencionó anteriormente. Para esto se
emplean las tarjetas FDSP (ó FDSPE). Estas tarjetas analizan el canal de voz intentando detectar
tonos DTMF en una llamada, que serán un dato más a incluir en los futuros CDR que se obtendrán
en el servidor. La información extraída de los canales de voz es enviada hacia el servidor a través
de la interfaz Ethernet de la tarjeta I/O MCPU.
La tarjeta I/O MCPU posee su propia dirección IP para el envío de datos hacia el servidor. Estos
datos son los procesados por una tarjeta MCPU. MCPU es el núcleo de la Sonda. A través de esta
tarjeta se establece el control de todos los componentes del equipo. MCPU permite el intercambio
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 30
de datos entre las diferentes tarjetas a través del bus PCI, gestiona de manera centralizada las
alarmas y otros mensajes emitidos por los diferentes componentes y envía esta información al
servidor de gestión del equipo. También MCPU es quien mantiene la configuración del software del
equipo.
La sonda envía hacia el servidor una serie de datos adicionales para su incorporación al CDR. El
identificador (ID) de cada equipo y la fecha y hora de captura del mensaje de señalización son
datos que se incluyen en el pre-CDR.
La tarjeta I/O OCDI cuenta con unos interruptores de rápida conmutación que realizan un by-pass
para las líneas tomadas de manera intrusiva (conexión serie de la Sonda). Esto permite que no se
afecten las llamadas telefónicas cuando exista una falla en el equipo. La conexión intrusiva no
supone tomar muestras de los flujos de datos con una conexión paralela como aparece en la figura
6, sino que la sonda se conecta en serie con el flujo de datos, interviniéndolo totalmente. Esta
configuración de instalación de la sonda se utiliza cuando se van a tomar enlaces de voz, y
específicamente se utiliza para poder implementar el bloqueo de llamadas.
Existe una versión compacta de esta Sonda, el modelo PRBm-20. Las características y
especificaciones técnicas de este modelo se pueden consultar donde indica la referencia 14.
Software de gestión
Existe el software RADview para la configuración y gestión de la Sonda. Este software permite el
acceso a todos los recursos del equipo, incluso de manera remota. La Sonda tiene un puerto serie
para el acceso local a su configuración. También se puede acceder de manera remota a través de
la interfaz Ethernet de la tarjeta I/O MCPU; o a través de un canal dedicado de uno de los flujos E1
monitoreados.
La interfaz del usuario puede ser a nivel de comandos, mediante un menú de texto o gráfica. En
cualquiera de los casos se tiene acceso completo a la configuración del equipo y sus
componentes.
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 31
Fig. I.7. Interfaz de usuario para gestión de la Sonda (Telnet)
I.4.2 Sonda NSTS. Breve descripción
NSTS es un sistema de vigilancia para redes de telecomunicaciones, según lo define la firma
Cibertec Int. radicada en Costa Rica. Este sistema está destinado a monitorear el tráfico en la red
telefónica analizando el contenido de la señalización no. 7. Además de su función principal de
adquisición de información para un sistema antifraude, NSTS puede emplearse como un sistema
de medición de la calidad de la red. De esta manera logra dar seguimiento al comportamiento de
diferentes parámetros en la red como congestión, demora en la respuesta a los mensajes, entre
otros. También es capaz de interpretar el tráfico SMS (en inglés, Short Message Service) en redes
de telefonía celular.
Una configuración mínima de una Sonda de Cibertec estaría compuesta por:
� Una tarjeta de adquisición de datos de la PSTN (SS7 y voz)
� Una tarjeta DSP para el análisis de los canales de voz
� Un controlador (Servidor)
� Un módulo BK-7 (para el bloqueo de las llamadas)
La interfaz de adquisición de datos se sincroniza con las tramas E1 y toma la información de la
señalización de los flujos inter-centrales. De estos flujos extrae los mensajes de señalización y los
envía al Controlador. La tarjeta está preparada para la asimilación de varios canales de
señalización sobre un mismo flujo, por lo que se puede conectar a la salida de un concentrador de
flujos.
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 32
Se conoce que las tarjetas de adquisición fueron diseñadas mediante la herramienta software
Orcad y empleando microcontroladores. El firmware de los controladores se almacena en
memorias EEPROM. Cada tarjeta es capaz de asimilar hasta 31 canales de señalización,
independientemente de la cantidad de flujos E1 que permite conectar (8 intrusivos ó 16 no
intrusivos).
La configuración previa de la tarjeta de adquisición debe indicar de cada flujo E1 cuáles canales
son de señalización y cuales de voz. Para el análisis de la voz, la tarjeta envía los datos de los
canales correspondientes para su procesamiento a la tarjeta DSP a través de un bus abierto de la
firma Mitel (ST-Bus). Los datos pre-procesados (fundamentalmente tonos DTMF) son enviados
posteriormente al Controlador. Toda la comunicación entra las tarjetas se lleva a cabo a través del
ST-Bus. La toma de canales de voz se realiza mediante conexiones intrusivas. El sistema
garantiza la continuidad de las líneas de datos al retirar o salir de funcionamiento una tarjeta de
adquisición, con lo cual no se interrumpe la comunicación.
Cada tarjeta (adquisición y DSP) contiene un módulo HDLC. Este permite la comunicación de las
tarjetas con los Controladores a través del protocolo HDLC.
El Controlador realiza tareas de interpretación de la señalización. En este punto se filtran los
mensajes que son de interés del sistema de monitoreo. De los mensajes relativos al proceso de
establecimiento y liberación de llamadas, el Controlador extrae los campos necesarios para
conformar un CDR. Estos datos son enviados posteriormente a un servidor de BD. El Controlador
almacena además las configuraciones del resto de los componentes del sistema. A través de este
se lleva a cabo también la gestión de las tarjetas de adquisición y la DSP. En un sistema con
dimensiones considerables, pueden utilizarse varios Controladores, entre los cuales se comparte
la carga del análisis de los mensajes de la señalización.
Existe un Controlador dedicado exclusivamente al proceso de bloqueo de llamadas (Controlador
BK-7). A este servidor se envían los datos de aquellas llamadas que se requiere bloquear. Este
dato lo aporta el sistema antifraude. El servidor envía esta orden a una tarjeta de adquisición cuyo
firmware responde a las tareas de un módulo de bloqueo. Esta tarjeta tiene asociado un código de
punto de señalización propio, con lo cual puede enviar mensajes de señalización a la PSTN. La
tarjeta necesita recibir el punto de origen, punto de destino y código identificador del circuito de la
llamada que se quiere bloquear. Con estos datos conforma los mensajes REL y RLC (mensajes de
liberación de llamadas), según corresponda mediante el cual lleva a efecto la terminación de esa
llamada [16] [18].
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 33
I.4.3 Sondas IP
En los últimos años ha habido una tendencia a implementar más servicios sobre el protocolo IP,
como la voz (VoIP), telefonía (ToIP) y televisión (IPtv). Por otra parte la difusión de contenido
multimedia y las novedosas redes de próxima generación (NGN) también le han dado un
protagonismo significativo al protocolo IP. Esta convergencia de servicios requiere de redes con un
mejor rendimiento y calidad, por lo que la implementación de sistemas de control se hace
imprescindible para la evaluación del desempeño de las redes.
En este contexto aparecen las sondas IP. Estos dispositivos están orientados a la medición de
parámetros del funcionamiento de la red, con el objetivo de determinar fundamentalmente demoras
en las respuestas, congestiones, pérdida de paquetes, entre otros. Evidentemente, estos
inconvenientes van en detrimento de los servicios que brinda la red. Teniendo en cuenta que
muchos servicios de comunicaciones también se implementan sobre el protocolo IP, una Sonda en
este ámbito puede estar orientada también a registrar los eventos de inicio y fin de sesión. Esta
última funcionalidad las hace idóneas como fuente de información para los sistemas antifraude.
Si bien la tecnología y estructura de diseño de las sondas anteriores responde a equipos o
sistemas compuestos, las sondas IP pueden implementarse también mediante software o sistemas
embebidos como se verá seguidamente.
Sistema ORENETA
ORENETA (One-way delay REaltime NETwork Analyzer) es una plataforma de análisis para redes
IP orientada a la medición de parámetros de calidad de los servicios de red. Específicamente se
centra en la medición de los retardos y sus variaciones para servicios de tiempo real. La
herramienta provee a los administradores de una interfaz visual para el análisis comparativo de la
implementación de las diferentes políticas de gestión de la red en tiempo real.
El sistema se compone de dos sondas ubicadas en diferentes puntos de la red. Estas actúan en
modo pasivo, o sea, no interfieren en el tráfico muestreado. Esta configuración garantiza realizar
un chequeo más exacto sobre el tiempo de recorrido de los paquetes, ya que no ocurre
interferencia durante la captura.
Los paquetes capturados son enviados a un analizador (software) el cual realiza los cálculos
correspondientes según las mediciones tomadas. El analizador separa el total de paquetes
capturados en flujos unidireccionales. El análisis de los flujos en un sentido y de manera
independiente garantiza realizar una caracterización más exacta del tráfico. Las funciones de
gestión y control de las sondas se realizan desde el mismo analizador.
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 34
Para las mediciones diferenciales de tiempo que realiza este sistema, requiere que las sondas se
encuentren sincronizadas. Para lograr tal cosa se utiliza el protocolo NTP (Protocolo de tiempo de
red). No obstante, este protocolo no es eficiente para estas mediciones cuando las sondas se
encuentran próximas (en cuanto a su conexión en la red). Luego, las sondas también utilizan una
fuente de sincronización externa como GPS (Sistema de Posicionamiento Global).
La marca del tiempo de captura de los paquetes se realiza a nivel de aplicación. Esto introduce un
margen de error que según el fabricante es despreciable.
Las sondas de ORENETA asimilan paquetes IPv4 e IPv6. Estas marcan cada paquete con un
identificador que generan mediante la función CRC-32 utilizando información de la cabecera del
propio paquete. En total una Sonda envía 28 octetos de información al analizador por cada
paquete IPv4 interceptado y 42 octetos por cada paquete IPv6.
Este sistema realiza un monitoreo de manera pasiva, por lo que no introduce ningún flujo de
paquetes adicional en la red. El modo pasivo tiene el inconveniente de no poder utilizar la marca
de los paquetes IP pues en ocasiones se le elimina por cuestiones de seguridad, y en el caso de
IPv6 no existe. Por tal razón, es necesario generar una marca para cada paquete antes de enviarlo
al analizador, como se explica en el párrafo anterior.
Tanto las sondas como el analizador se implementan sobre microcomputadoras, sin otro hardware
adicional. Las sondas efectúan la captura de los datos de la red mediante las tarjetas de red
estándar y haciendo uso de la librería libpcap aplican los filtros necesarios para la discriminación
de paquetes. Los requerimientos de hardware y software del sistema se detallan en la siguiente
tabla.
Tabla I.1. Requerimientos HW/SW de ORENETA
Sondas Analizador
Hardware PC Pentium III, 600 MHz PC Pentium IV, 2.4 GHz
Software C++ / GNU-Linux Java / Multi-plataforma
Además de soportar el protocolo IP, el fabricante asegura que las sondas pueden operar en redes
ATM e inalámbricas [19].
LIMS (Light Weight IP Measurements System)
Como su nombre lo indica, este sistema está destinado para realizar mediciones sobre una red IP.
LIMS específicamente está concebido para medir de manera continua y en tiempo real diferentes
parámetros de calidad de la red como la disponibilidad de conexión a nodos IP, la latencia
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 35
(distancia temporal entre nodos), el jitter (variación de la latencia entre paquetes consecutivos) y el
ancho de banda.
La infraestructura de LIMS se compone de:
� Sondas IP
� Servidores STUB
� Servidor Central
Los servidores STUB llevan a cabo las tareas de medición de conjunto con las sondas. Estos
responden a estímulos enviados por las sondas y generan transacciones que luego son
monitoreadas por estas. Estos servidores son del tipo Sun FIRE V100 con un Sistema Operativo
Solaris 10.
Al servidor central se envían los resultados de las mediciones, se almacena la configuración de los
componentes del sistema y se lleva a cabo la gestión de estos a través de una red dedicada. El
servidor es del tipo Sun FIRE V440 con un Sistema Operativo Solaris 10.
Las sondas están destinadas a la captura de los paquetes de red y a realizar algunas tareas de
mediciones de los parámetros de calidad. Los resultados de las mediciones efectuadas los envían
al Servidor Central a través de una interfaz Ethernet.
Las sondas fueron diseñadas en un Sistema Linux Embebido. Para esto se empleó un kit de
desarrollo del tipo Vortex 86-6076L2/EB-303 con un núcleo GNU-Linux versión 2.4. Algunas de las
características del componente hardware se relacionan en la tabla 2.
Tabla I.2. Especificaciones del Kit de desarrollo Vortex 86-6076
SoC Microprocesador DM&P Vortex86 a 200 MHz
Bus PCI (32 bits) compatible con PCI Rev. 2.2
Memoria 128 MB (SDRAM on board)
Interfaz LAN Controlador Realtek 8100B, 10/100 Mbps
Interfaces I/O Puerto Paralelo RS 232 USBIDE
Las sondas se caracterizan por su bajo coste de inversión, contando con un sistema operativo
gratuito. La protección contra intrusiones en el dispositivo se garantiza mediante el cortafuegos
IPCop. El sistema Linux empleado es de código abierto, luego, el diseño de la Sonda puede
evolucionar de manera muy fácil [20].
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 36
I.4.4 Valoraciones sobre las sondas descritas
Las diferentes sondas estudiadas arrojan una gama de estructuras y tecnologías diversas. La
Sonda de la RAD exhibe un excelente nivel de especialización en cuanto a sus módulos. Posee
una capacidad de 20 flujos de entrada, lo cual significa una capacidad de análisis de 620 canales
entre señalización y voz. Las interfaces gráficas de usuario para la gestión son muy intuitivas y
completas, teniendo acceso a todas las opciones de configuración del equipo. A pesar de esto se
ha demostrado en su operación numerosas trazas de llamadas que la sonda no ha registrado.
Desde el punto de vista de seguridad, la nacionalidad del fabricante constituye en sí un riesgo
potencial para nuestro país por razones políticas conocidas. Luego no se descarta la posibilidad de
puertas traseras para desvíos de información, así como de interrupciones provocadas en la
solución implementada en ETECSA. Las sondas conectadas de manera intrusiva pueden
interrumpir las comunicaciones de ETECSA con el extranjero manteniendo abiertos los circuitos de
enlaces de las centrales internacionales.
En cuanto al sistema NSTS, posee una estructura eficiente para la adquisición y clasificación de
los datos tomados de la red telefónica. Su tecnología de diseño basada en microcontroladores lo
hace un prototipo de fácil reconfiguración con posibilidades viables de evolución en cuanto a
desempeño y funcionalidades. Sin embargo, el uso de aplicaciones software en el sistema posee
varios inconvenientes. El procesamiento software de la señalización es más lento que si se
empleara un sistema hardware, como en el caso de la RAD. Por otra parte, el empleo del STBus
de Mitel hace el diseño poco flexible. En su lugar, la sonda de la RAD usa el bus PCI,
estandarizado y de alta velocidad. El sistema de monitoreo se encarece por el costo de los
servidores; a la vez que se incrementa el riesgo de ataques informáticos, intrusiones y virus; y la
probabilidad de fallos en el sistema es elevada dadas las complejidades intrínsecas de un sistema
operativo involucrado.
Las sondas IP mantienen un objetivo común: las mediciones de parámetros en la red. De ellas no
son muy publicitadas por los fabricantes sus posibilidades de interceptar la información relativa al
inicio de sesión de usuarios, lo cual sería una alternativa viable para la implementación de un
sistema antifraude en redes NGN. En las sondas IP se observa el uso de los sistemas embebidos,
lo cual ofrece la ventaja del procesamiento hardware de los datos, con lo que se logra una mayor
velocidad con respecto al procesamiento software.
Además de los costos de adquisición y mantenimiento elevados de las sondas, tienen un aspecto
de considerable interés en contra. Estos equipos pueden comportarse como elementos activos en
Capítulo I
Diseño de un sistema para el monitoreo de la señalización no.7 37
las redes, a través de los cuales se establece el flujo de datos. Al ser de factura extranjera, con
tecnología propietaria, los detalles de la programación y diseño de sus módulos (tanto SW como
HW) son desconocidos y no revelados por el fabricante. De manera que solo se logra conocer lo
que el vendedor dice y demuestra que hace. Estos equipos, por sus características, son ideales
para implementar “puertas traseras”, por donde pueden llevar a cabo el desvío de información, la
re-configuración del HW para determinados objetivos especiales, interrupciones provocadas o
fallas de funcionamiento temporales o definitivas. Mecanismos similares a las bombas lógicas, o la
re-programación de determinados circuitos integrados (CI) on board permiten lo mencionado
antes. Por otra parte, el soporte técnico especializado corre a manos de especialistas extranjeros.
Todo esto hace que se incurra en un riesgo potencial al instalar este tipo equipamiento en nuestras
redes.
Lo anterior constituye, además del factor económico, una razón más que demuestra la necesidad
de disponer de un sistema de monitoreo propio.
Conclusiones
El estudio del protocolo de señalización SS7 indica que existen los conocimientos y la
documentación suficientes como para diseñar un sistema capaz de interpretar sus mensajes y
detectar así comportamientos fraudulentos sobre la red telefónica.
Por otra parte, las características que se han descrito de las sondas, dan una medida de que es
posible llevar a cabo el diseño de un equipo similar en nuestro país para el monitoreo de la
señalización no.7, dado que se cuenta con la tecnología necesaria para esto.
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 38
Capítulo II. Tecnología y diseño del sistema de monitoreo
Introducción
Los FPGA (Arreglo de Compuertas Programables) son circuitos integrados programables similares
a los microcontroladores o los PLD (Dispositivos Lógicos Programables). Esta tecnología ha
impulsado el proceso de desarrollo de hardware imprimiéndole una mayor velocidad. De hecho,
hoy en día, un gran número de los sistemas electrónicos profesionales cuentan con FPGA como
componentes fundamentales y el diseño de hardware digital ha transitado vertiginosamente de la
pura interconexión de circuitos integrados con funciones específicas a la programación software de
dispositivos programables.
Las tarjetas de evaluación de estos dispositivos poseen múltiples recursos periféricos, que en el
caso del sistema que se presenta en este trabajo, resultan de gran utilidad. Algunas de las
características de una tarjeta de evaluación Spartan-3 Starter Kit se relacionan a continuación:
Hasta 173 señales de entrada-salida disponibles
4 DCM
Memoria PROM Flash de 2 Mb
Memoria SRAM de 1 MB (dos bancos de 256Kx16)
1 puertos serie RS-232 de 9 pines
Puerto VGA de 3 bits (8 colores)
Oscilador de 50 MHz
Fundamentalmente por la disponibilidad, por muchas de sus características y por las facilidades
que ofrecen las herramientas de desarrollo de Xilinx, se escogió esta tarjeta de evaluación
Spartan-3 Starter Kit para el diseño del sistema de monitoreo de la señalización. No obstante,
como se verá más adelante, se necesita una interfaz Ethernet, que no se incluye en esta tarjeta.
Posteriormente se detallará la solución encontrada, sin embargo, sería deseable emplear otro
modelo que contara con este recurso; el Spartan 3A Starter Kit, por ejemplo.
II.1 FPGA de Xilinx. Generalidades
II.1.1 Detalles de la estructura de un FPGA
Las potencialidades de los FPGA hacen que se puedan agrupar en ellos un gran número de
funciones y componentes complejas que antes constituían cada una un circuito integrado. De aquí
que se denomine System on Chip (SoC) a todo un sistema encapsulado enteramente en un FPGA.
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 39
La arquitectura de un FPGA consiste en cinco elementos programables fundamentales:
1. CLB (Bloques Lógicos Configurables)
2. IOB (Bloques de entrada-salida)
3. BRAM (memoria RAM de bloque)
4. Multiplicadores
5. DCM (Manejador de reloj digital)
Los CLBs se pueden programar de diversas maneras logrando así una amplia gama de funciones
lógica. Cada CLB está compuesto por cuatro slices y estos a su vez contienen las llamadas LUTs
(en inglés, Look up tables), las cuales son elementos basados en memoria RAM que se pueden
usar como flip-flops ó latches. Las LUTs pueden tomar la forma de un bloque lógico e implementar
multiplexores, o bien utilizarse como elementos de memoria RAM distribuida. En la referencia 20,
en las páginas 10 y 11 se observan diagramas de bloque que detallan la estructura de un CLB.
Los IOBs se encargan del flujo de datos desde y hacia el FPGA a través de los pines del chip.
Soportan flujos de datos bidireccionales, operaciones tri-estados, y un total de 24 estándares de
señales incluyendo siete estándares diferenciales de alto desempeño. Poseen además control
digital de impedancias. En la figura de la página 2 de la referencia 20 se observa un diagrama de
este elemento.
La RAM de bloque se compone de varios bloques de 18 Kbits. Cada uno se comporta como un
chip de memoria de doble puerto. Cada puerto tiene sus propias señales de control para las
operaciones de lectura y escritura.
Los multiplicadores son bloques dedicados que efectúan esta operación entre dos números de 18
bits cada uno. A la salida se obtiene un número de 36 bits. Se puede asociar un bloque
multiplicador con un bloque de RAM.
Por su parte, los DCM están destinados a proveer una señal de reloj de gran exactitud. Eliminan
los cambios de fase en la señal de reloj, así como las desviaciones de esta señal producto de
perturbaciones externas, de altas temperaturas u otros efectos. Para esto implementan un DLL
(Delay-Locked Loop, en inglés).
II.1.2 Desarrollo de sistemas con FPGA
La herramienta Xilinx Project Navigator se utiliza para desarrollar los sistemas basados en FPGA.
Esta herramienta muestra los recursos disponibles para el desarrollo, permite visualizar errores y
otro tipo de información durante el flujo de diseño. Además transfiere datos entre diferentes
herramientas complementarias.
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 40
La primera de las etapas en el flujo de diseño es la “Descripción”. Esta etapa consiste en realizar
los componentes que conformarán el sistema. Para esto existen dos variantes: hardware y
software. La figura 10 muestra un diagrama del flujo de desarrollo de un proyecto utilizando la
herramienta Xilinx Project Navigator.
Fig. II.1 Flujo de diseño con de FPGA con ISE
Los componentes hardware se configuran en una interfaz para diseños esquemáticos. Existe un
grupo de módulos como contadores, multiplicadores, multiplexores, etc., que se pueden configurar
e interconectar en esta interfaz. Además existen las mega-funciones, que son los mismos módulos
mencionados pero sobredimensionados en sus características.
Los componentes software son programados en un editor para lenguajes HDL o Verilog. Mediante
estos editores se realizan módulos hardware pero describiendo su estructura y funcionalidad a
través de código software.
En la etapa de descripción puede usarse un editor de máquinas de estado y un generador de
módulos IP. Los módulos IP son componentes hardware diseñados por el desarrollador, aunque
algunos los provee el fabricante. Estos pueden ser diseñados en un editor de esquemáticos o en
un lenguaje de descripción de hardware. Estos módulos pueden reutilizarse en otros diseños y
esta es su ventaja fundamental; la reusabilidad. Un módulo IP puede contener las funciones de un
microcontrolador, como es el caso de “Orégano”, o de un microprocesador, como MicroBlaze, del
cual se hablará más adelante.
Una segunda etapa en el flujo de diseño con ISE es la “Síntesis”. Además de los componentes
logrados, se deben definir las restricciones del diseño como dato necesario para este proceso.
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 41
Durante la síntesis se detectan los errores de sintaxis, se analiza la jerarquía entre los
componentes, se identifican e implementan las macros dentro del diseño, se lleva a cabo una
optimización en cuanto a tiempo y se mapean los componentes del sistema.
Como resultado del proceso anterior se genera un fichero de trazas y un fichero netlist que sirve
como entrada para el proceso de implementación.
Durante la etapa de implementación se combinan varios ficheros de descripción de componentes
en un solo fichero netlist, mediante el proceso Ngdbuild de ISE. También se hace corresponder
cada símbolo lógico resultado del netlist con componentes físicos del FPGA. El proceso Place and
Route ubica los componentes en el FPGA y los interconecta. Esto puede modificarse
posteriormente por el desarrollador pero no es recomendable, pues este proceso se lleva a cabo
optimizando los recursos de espacio y teniendo en cuenta las rutas más factibles para la
interconexión de los elementos.
Antes de programar el FPGA se puede verificar el diseño mediante herramientas de simulación
como ModelSim, y realizar análisis de tiempo con el Xilinx Time Analyzer. Estas herramientas
brindan una fiabilidad mayor aún para garantizar que el diseño se encuentre libre de errores.
Por último se programa el FPGA. En el caso de los kits de desarrollo como el de Spartan 3, es
posible programar directamente el FPGA o se puede programar la memoria PROM de
configuración de la tarjeta [21].
II.1.3 Procesador MicroBlaze
El procesador MicroBlaze es un procesador RISC (Set de Componentes de Instrucciones
Reducidas) de 32 bits, desarrollado por Xilinx. El mismo es compatible con las familias Spartan y
Virtex. MicroBlaze cuenta con una arquitectura Harvard con buses de 32 bits separados para
acceso a datos e instrucciones y permite el acceso a estos recursos a través de memoria cache.
Actualmente cuenta con interfaces para los buses OPB, LMB y PLB. Además cuenta con un
protocolo XCL para el acceso a la memoria cache de datos e instrucciones cuando está habilitado
este recurso.
El repertorio de instrucciones de MicroBlaze es el típico repertorio de un procesador RISC. En total
cuenta con 87 instrucciones diferentes. Se incluyen operaciones de multiplicación hardware a partir
de la familia Spartan 3. Este procesador cuenta con 32 registros de 32 bits cada uno, de los cuales
14 son de propósito general. Cuenta con cinco etapas máximo para la ejecución de instrucciones
(arquitectura pipeline), con lo cual es capaz de tener lista una instrucción completa en cada ciclo
de reloj.
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 42
MicroBlaze es un procesador basado en código software, al contrario de su homólogo, el PowerPC
que es un módulo hardware y viene ya empotrado en los FPGA de la familia Virtex (modelo Fx en
adelante). MicroBlaze posee un grupo extenso de parámetros configurables que brindan cierta
flexibilidad para el desarrollador a la hora de diseñar un sistema [22].
II.1.4 Desarrollo de sistemas basados en microprocesadores
Con la herramienta Xilinx Platform Studio (XPS) es posible diseñar una infraestructura hardware o
“plataforma” donde el núcleo del sistema sea un microprocesador empotrado. XPS soporta una
amplia gama de familias de FPGA de Xilinx; así como incluye varios modelos de placas de
desarrollo.
En una plataforma se integran componentes hardware y software según los requerimientos de la
aplicación. Existen controladores de memoria, interfaces de comunicaciones, generadores de
señal de reloj, módulos de verificación y depuración, etc. Estos componentes se interconectan a
través de sus señales de entrada-salida y de buses fundamentalmente y son altamente
configurables. Los drivers (manejadores) para estos componentes incluyen funciones mediante las
cuales el desarrollador puede configurar e interactuar con los mismos. Los drivers pueden incluir
funcionalidades como generación de interrupciones, DMA y funciones de auto chequeo.
El diseño basado en plataforma tiene la ventaja de poder utilizar la misma infraestructura hardware
para el diseño de otro prototipo. O sea, se cumple aquí también el principio de reusabilidad. Este
principio implica un ahorro considerable de tiempo de ejecución de un proyecto.
A los componentes en el diseño se les asigna un espacio de direcciones lógicas. Estas direcciones
se pueden asignar manualmente o automáticamente por la herramienta. Se pueden definir
parámetros explícitamente para cada componente en el fichero system.mhs y algunas condiciones
específicas en el fichero system.ucf.
Es necesario configurar también la plataforma software del sistema, definiendo principalmente los
drivers de cada dispositivo y el sistema operativo que se usará. La versión 10.1 del EDK (en inglés,
Embbeded Development Kit) incluye los sistemas operativos “standalone” y “xilkernel”, entre otras
opciones. Este último posee características avanzadas como la programación multi-hilos, uso de
semáforos, programación de tareas y temporización; en tanto el “standalone” provee solo
funciones básicas para procesadores y funciones comunes de entrada-salida [23] [24].
El entorno del XPS tiene una opción para la etapa de simulación que genera una plataforma
virtual. La plataforma virtual consiste en emular el funcionamiento de una placa de desarrollo.
Sobre esta se monta el diseño y se puede simular generando los ficheros de simulación
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 43
correspondientes. La plataforma virtual tiene limitaciones con las versiones del MicroBlaze, pues
no las acepta todas y tampoco acepta el bus PLB. No obstante es una opción a tener en cuenta
para la puesta a punto de un diseño con XPS.
II.2 Diseño del sistema
En este apartado se definirán las características que debe tener el sistema. Para ello se determinó
acometer el diseño en dos fases, cada una con sus requerimientos. La fase primera contemplará el
desarrollo de un sistema funcional que garantice las operaciones básicas con los mensajes de la
señalización no.7, tales como la adquisición, análisis y transmisión de los mensajes. La segunda
fase contendrá básicamente el desarrollo de una interfaz de gestión del equipo; así como algunas
mejoras desde el punto de vista de su diseño, incluyendo las posibilidades de expansión de líneas
de entrada. El diseño que se presenta en este trabajo pretende cumplimentar lo planteado en la
fase primera solamente.
II.2.1 Requerimientos
Fase I. Diseño de un sistema para el monitoreo de la señalización no.7
El diseño del sistema debe garantizar la captura, análisis, selección y transmisión de los mensajes
SS7 contenidos en las tramas E1 que se generan en los enlaces de señalización entre las
centrales telefónicas.
Se considerarán como señales de entrada una trama E1 proveniente de un concentrador de flujos
y una señal de reloj para el sincronismo de los datos. No se usará codificación de línea; o sea, se
considerará una transmisión del tipo NRZ unipolar. El sistema debe soportar multitramas de 2 ó 16
tramas E1 y no tendrá en cuenta la existencia de los bits de redundancia CRC-4.
Entre dos centrales telefónicas cualesquiera, el enlace de señalización ocupa 2 canales de una
trama E1 (un canal de subida y un canal de bajada), según la Rec Q. 703 de la UIT. Debe tenerse
en cuenta que cada canal de la trama E1 de entrada a nuestro sistema contiene la información de
un canal de un enlace de señalización. Se tomará además la información del enlace de
señalización de reserva, por lo cual entre dos centrales se ocuparán 4 canales de un E1. Cada
flujo E1 tiene capacidad para transportar 31 canales de datos; por lo que el sistema podría
garantizar el monitoreo de los enlaces de señalización de una central contra otras siete, quedando
aun 3 canales libres.
Dado que el objetivo es conformar una base de datos con las trazas de las llamadas, solo será
necesario el muestreo de los mensajes de señalización referentes al inicio y liberación de las
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 44
llamadas, descartando el resto. Los mensajes seleccionados se enviarán a un servidor en su
mismo formato, eliminando solamente la bandera de inicio y el campo CRC. Además, se añadirán
a cada mensaje el identificador del equipo que lo capturó y un código pseudo aleatorio. Este
código será verificado posteriormente en la aplicación que reciba los datos para garantizar la
autenticidad del origen mensaje.
Aunque no es necesario incluir el campo CRC al efectuar el envío de los datos, el sistema debe
garantizar que estos se encuentren libres de errores de transmisión y solo entonces se procederá
a su entrega al servidor. Esto significa que se debe descartar todo aquel mensaje que contenga
errores de redundancia cíclica.
Los mensajes SS7 seleccionados serán enviados a un servidor para su posterior inclusión en una
BD. Como requerimiento se establece que la transmisión de los datos se efectuará mediante el
protocolo Ethernet, utilizando el estándar 10/100 BaseT, según la Rec G.802.3 de la UIT. Se
requiere una velocidad de transmisión de 100 Mbps en la conexión entre el equipo y el servidor.
El sistema generará señales de alarma por mal funcionamiento o detección de errores en la línea
de entrada de datos; así como por pérdida de sincronismo. También debe disponer de la
posibilidad de reiniciarse automáticamente al detectar errores críticos en su operación. Así mismo,
debe poder reiniciarse por una orden externa emitida desde una futura interfaz de gestión.
Fase II. Diseño de una interfaz de gestión e incremento de la capacidad y fiabilidad del
sistema
En la primera fase se concibe el diseño para la adquisición de un solo flujo E1; sin embargo, será
necesario en esta etapa incrementar la cantidad de líneas de entrada entre 4 y 8, aunque se
mantendrá en 31 el número máximo de enlaces de señalización que serán manejados por una
sonda. Esto brinda la posibilidad de prescindir del concentrador de flujos para determinadas
aplicaciones.
Deben determinarse las características físicas de las interfaces externas, tales como la impedancia
de entrada de las líneas E1 y el tipo de conector que se usará, el alcance máximo de las señales
de salida y se definirá la interfaz de entrada para la gestión del sistema. Además, debe poder
admitirse la codificación HDB3 en la línea de entrada de datos. También se debe pasar de la
transmisión Ethernet pura a transmisiones TCP/IP.
Se debe determinar el consumo energético total del equipo; así como la fuente de alimentación
que se usará.
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 45
Como cuestión más importante, se debe diseñar una interfaz de gestión (software) para obtener
reportes de operación, alarmas y fallas propias del equipo. También deberá servir para configurarlo
de manera remota. Debe incluirse además, la posibilidad de realizar un auto-chequeo para la
comprobación del estado de los parámetros fundamentales del equipo en determinado momento.
A través de la interfaz de gestión se deberá implementar un mecanismo de generación de códigos
para la verificación de la autenticidad de los mensajes que emita el sistema de monitoreo. El envío
de estos datos debe garantizarse de manera segura, debiéndose utilizar algún método de cifrado.
Debe incluirse además, la posibilidad de encriptar, antes del envío, los mensajes que involucren
determinados números telefónicos introducidos por el usuario del sistema a través de la interfaz de
gestión mencionada.
II.2.2 Etapa de desarrollo del sistema (fase 1)
Introducción
El diseño del equipo se acometió de manera modular. Es posible distinguir un bloque de
adquisición de datos, una parte para el procesamiento de los datos y una parte para la transmisión
vía Ethernet, aunque estas dos últimas están estrechamente relacionadas en el código de la
aplicación. Esta delimitación permite la escalabilidad del diseño para su adaptación a otras
tecnologías de acceso y protocolos; así como el uso de los módulos en otros proyectos.
Como plataforma para el diseño del hardware se empleó el Xilinx Platform Studio contenido en la
versión 10.1 de Xilinx ISE Design Suite. Al utilizarse un microprocesador empotrado, se diseñó
además una aplicación software en lenguaje C++. La misma fue programada y compilada
enteramente en el Xilinx Platform Studio SDK (XPS-SDK).
Además de estas herramientas, se empleó la plataforma Max Plus II de la firma Altera. Dadas las
facilidades que brinda su entorno de desarrollo y simulación para programar en lenguaje VHDL.
Los resultados de la simulación de los componentes para la adquisición de datos que se mostrarán
en el trabajo, se obtuvieron utilizando Max Plus II. Posteriormente se construyó un módulo IP en
XPS donde se integraron los componentes de la adquisición de datos.
La estructura del proyecto exhibe un diseño híbrido HW-SW, donde se combinan módulos IP
propios del fabricante Xilinx, un módulo IP del autor y el código fuente desarrollado en lenguaje
C++. Las funciones necesarias para la adquisición de los datos se acometen a través del módulo
IP exclusivamente diseñado para esto, enteramente en lenguaje VHDL.
Infraestructura HW
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 46
La tecnología escogida para acometer el proyecto fue un kit de desarrollo Spartan 3 Starter Kit
basado en el componente FPGA de Xilinx Spartan 3, modelo xc3s1000ft256. La capacidad de este
dispositivo permite descargar la estructura del proyecto en su totalidad y aún queda un margen
para implementar algunas mejoras, como las contempladas en la fase segunda.
La infraestructura HW del diseño está basada en el uso de un microprocesador MicroBlaze
empotrado en un proyecto del tipo SoC desarrollado en EDK. Se configuró el acceso a memoria
cache mediante el uso de los bancos de memoria SRAM contenidos en el kit de desarrollo. Se
configuró el acceso a cache para instrucciones y datos tomando 8 KB para cada uno de los
segmentos. El acceso a esta memoria se garantiza a través de los protocolos XCL (Xilinx Cache
Link), los cuales son exclusivos para estas operaciones. Ver diagrama del proyecto en el anexo 4.
En el diagrama del proyecto se puede observar además, una memoria RAM de bloque de 16 KB
(BRAM) con los buses de instrucciones y datos separados (“ilmb” y “dlmb” respectivamente),
conectada esta al microprocesador siguiendo una arquitectura Harvard.
Para el control de las señales de los bancos de memoria se empleó un controlador de memoria
externa multi-canal (“xps mch emc”). Sus características permiten utilizar ambos canales de la
SRAM para el acceso individual a cache. La SRAM posee además una conexión al bus PLB que
se destinó para el intercambio de los mensajes de señalización. En el proyecto se establecen
como puertos externos al FPGA los buses de dirección y datos de la memoria externa; así como
sus señales de control. Se utilizó el módulo IP “bus splitter” para limitar el tamaño del bus de datos
del “xps mch emc” y hacerlo coincidir con el de la SRAM. El módulo “bus splitter” asimila a la
entrada un bus de datos de 32 bits y lo secciona dando a la salida dos buses de tamaños
configurables. A la salida del módulo se tiene un bus de datos de 16 bits para interactuar con la
memoria SRAM externa. Las señales de control, dirección y datos, como el resto de las externas
se relacionan a nivel de bit con pines específicos en el fichero system.ucf. Se observa una muestra
del contenido del fichero a continuación.
### Module SRAM constraints
Net fpga_0_SRAM_Mem_A_pin<15> LOC=j3; Net fpga_0_SRAM_Mem_A_pin<14> LOC=k3; Net fpga_0_SRAM_Mem_A_pin<13> LOC=k5; Net fpga_0_SRAM_Mem_A_pin<12> LOC=l3; Net fpga_0_SRAM_Mem_DQ_pin<31> LOC=n7; Net fpga_0_SRAM_Mem_DQ_pin<30> LOC=t8; Net fpga_0_SRAM_Mem_DQ_pin<29> LOC=R6; Net fpga_0_SRAM_Mem_DQ_pin<28> LOC=T5; Net fpga_0_SRAM_Mem_OEN_pin<0> LOC=k4; Net fpga_0_SRAM_Mem_CEN_pin<1> LOC=n5; Net fpga_0_SRAM_Mem_CEN_pin<0> LOC=p7;
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 47
Net fpga_0_SRAM_Mem_WEN_pin LOC=g3;
En el diseño se destinó el banco cero de la memoria externa para guardar las instrucciones y
datos del programa, así como para el espacio reservado a la cache. Luego, el banco 1 se destinó
al almacenamiento temporal de los mensajes que capture el sistema durante su operación. A partir
de la primera localización de memoria del banco 1 se comenzarán a almacenar los mensajes de
señalización. Cada mensaje ocupa un espacio no mayor de 280 bytes, por lo que el banco de
memoria externa SRAM es capaz de almacenar más de 900 mensajes al mismo tiempo, usando
solo el primer octeto de cada localización de memoria. Esta capacidad resulta suficiente, si se
tiene en cuenta que el flujo de datos de entrada es de 2 Mbps y el envío de datos al servidor,
según requerimientos es de 100 Mbps.
El módulo “xps mch emc” tiene la posibilidad de operar con frecuencias de más de 100 Mhz y
puede soportar hasta 4 bancos de memoria; por lo que se hace factible su empleo previendo un
aumento de la capacidad del sistema.
Se escogió una frecuencia de 100 MHz para la señal de reloj de entrada al sistema. El
procesamiento de los mensajes SS7 en determinadas funciones es complejo, luego se necesita
una velocidad de cómputo considerable. Además de esto, para lograr una velocidad de transmisión
de 100 Mbps en la interfaz Ethernet, es necesario una señal de reloj como la programada. Esta
señal la provee el módulo de reloj “clock generator”.
El diseño requirió además de un controlador de interrupciones (“xps intc”), ya que existen dos
fuentes de interrupciones: el módulo de adquisición de datos y el dispositivo Ethernet. Este
controlador se conecta al bus PLB y asimila a su entrada las peticiones de interrupción antes
mencionadas. Como resultado de al menos una de estas peticiones, el controlador genera una
petición de interrupción al microprocesador, para lo cual envía una señal al puerto correspondiente
del MicroBlaze. Se estableció como orden de prioridad mayor las solicitudes generadas por la
adquisición de datos, en tanto este módulo está atendiendo un flujo de datos en tiempo real. A
través de las funciones del driver del “xps intc” se conectaron las rutinas de atención de
interrupciones de la adquisición de datos y del “xps ethernetlite”. Las funciones conectadas, por
tanto, se ejecutarán tras detectarse su respectiva interrupción.
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 48
Fig. II.2 Esquema de interrupciones del sistema
Durante la realización de un módulo IP se puede configurar la generación de una señal de
interrupción. Luego, en la entidad aparece un puerto “IP2Bus_IntrEvent” destinado para este fin.
En el fichero user_logic.vhd contenido en el repositorio de módulos IP, mediante la instrucción
IP2Bus_IntrEvent <= "1";
se genera la señal de interrupción del módulo de adquisición de datos. Esta se genera cuando se
detecta la activación de la señal “ready_s” indicando la entrada de un octeto completo procedente
del flujo E1 monitoreado. El segmento de código siguiente (del fichero user_logic.vhd) muestra
esta condición.
if clkE1'event and clkE1 = '1' then if Bus2IP_Reset = '1' then slv_reg0 <= (others => '0'); else if ready_s = '1' then slv_reg0(0 to 7) <= octeto_s; slv_reg0(23) <= alarm_s(0); slv_reg0(31) <= LOF_alarm_s(0); case canal is when 0 => slv_reg0(8 to 15) <= "00000000"; when 1 => slv_reg0(8 to 15) <= "00000001"; … …
when others => slv_reg0(8 to 15) <= "00000000"; end case; IP2Bus_IntrEvent <= "1";
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 49
end if; end if; end if;
Uno de los requerimientos del prototipo es el envío de los mensajes SS7 seleccionados hacia un
servidor. Luego, otros dos periféricos empleados en el proyecto fueron el “mii to rmii” (Reduced
Media Independent Interface) y el “xps ethernetlite” para el control y la ejecución de las
transmisiones Ethernet. El módulo “mii to rmii” actúa como mediador. Está destinado a proveer una
mediación entre la capa física de las redes Ethernet y los módulos IP de Xilinx que interactúan con
esta tecnología, como el “opb ethernet”, “opb ethernetlite” y “plb ethernet”. Concretamente “mii to
rmii” acepta las 16 señales de los módulos Ethernet e interactúa con la capa física con solo seis o
siete señales de datos, con lo cual posibilita el uso del conector RJ-45 para aplicaciones con
acceso a redes de datos.
El “xps ethernetlite”, permite la transmisión y recepción de tramas Ethernet. El driver de este
dispositivo posee funciones que facilitan a bajo nivel la conformación de las tramas a transmitir,
incluso calcula y añade el CRC automáticamente a la trama que se configura para transmitir. Este
dispositivo cumple con las especificaciones del estándar 802.3 de la UIT. Posee la posibilidad de
operar en modo Fast Ethernet (100 Mbps). Además puede operar en modo de interrupción o en
modo DMA en transmisión o en recepción. Tiene un mecanismo de colas que permite acumular
tramas para la transmisión. Este módulo se conecta al sistema a través del bus PLB.
El periférico de mayor importancia es el de adquisición de datos. Este consiste en un módulo IP
diseñado exclusivamente para la toma de los datos que viajan a través de los enlaces de
señalización entre las centrales telefónicas. Este es el encargado de interpretar el flujo E1 de
entrada y enviar los datos al módulo de procesamiento.
Como parte del proyecto EDK existe un fichero (system.ucf) con algunas condiciones establecidas
por el desarrollador. Aquí se especifican las conexiones de las señales de entrada y salida de los
módulos IP con los pines del FPGA (incluyendo las señales externas). También se establecen
condiciones en cuanto a tiempo en dispositivos como el “xps ethernetlite” y el “mii to rmii”. Algunas
de estas condiciones, para determinados módulos IP, vienen indicadas en la hoja de datos del
fabricante.
Las señales de entrada-salida de la interfaz Ethernet, que pasan a través del “mii to rmii” se
conectaron a siete de los pines del conector de expansión A2 de la placa. A estos pines se puede
soldar un conector RJ-45 para la conexión del prototipo a un dispositivo de red o una computadora
directamente.
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 50
En cuanto a las señales relativas a la SRAM, se conectaron estas a los pines correspondientes
según indica la documentación del kit de desarrollo de Spartan 3.
El mapa de direcciones de los dispositivos se muestra en la tabla 3.
Tabla II.1. Mapa de direcciones
Direcciones (Base – High) Dispositivo
0000000000-0x00003fff BRAM
0x81000000-0x8100ffff XPS Ethernetlite
0x81800000-0x8180ffff XPS INTC
0x84100000-0x841fffff SRAM (banco 0)
0x84200000-0x842fffff SRAM (banco 1)
0xcfc00000-0xcfc0ffff Adq_E1
Módulo de adquisición de datos
La entrada de datos al equipo, como se ha comentado antes, es un flujo E1 compuesto por un
canal de sincronismo (canal cero) y 31 canales de datos. Cada uno de los canales transporta un
octeto con información de señalización (ver figura I.1).
Para garantizar la captura de tramas E1 alineadas se programó un componente (alinea_e1) en
VHDL. Este recibe directamente el flujo de entrada (señal “bits”), una señal de reloj de 2 Mbps de
sincronismo con el flujo de datos (señal “clk”) y una señal de reset (señal “reset”). Como resultado
de su operación genera una señal de salida para advertir que la transmisión E1 está sincronizada
(señal “sync”) y una señal de alarma para notificar la pérdida de sincronismo (señal “LOF_alarm”).
Se muestra un fragmento del código de programación del componente alinea_e1.
ENTITY alinea_e1 IS
PORT (clk :in std_logic; bits :in std_logic; reset :in std_logic; sync :buffer bit; LOF_alarm :out std_logic_vector (0 to 0)); END alinea_e1;
Se utiliza en la arquitectura de “alinea_e1” una estructura Process en cuya lista de sensibilidad se
incluye la señal de reloj. Aquí se evalúa cada bit de entrada con el objetivo de detectar las cadenas
FR (C001 1011) y NFR (C1xx xxxx); donde “C” es un bit que porta la información para corrección
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 51
de errores (CRC-4) para multitramas de 4 o 16 tramas E1. FR y NFR son los octetos que se
alternan en el canal de sincronismo de un flujo E1. Se considera que una trama está alineada si se
ha detectado una secuencia del tipo FR-NFR-FR ó NFR-FR-NFR. Esto quiere decir que se
necesitan tres tramas correctas, en cuanto a su canal cero, para considerar una transmisión como
sincronizada. De manera análoga se considera pérdida de sincronismo cuando se detecte una
secuencia distinta a las mencionadas anteriormente.
Para la detección de las cadenas FR y NFR se utilizó una máquina de estados de tipo Moore. Se
utilizó una codificación para los estados al estilo one-hot-zero, la cual simplifica la lógica
combinacional. La codificación empleada inicia el sistema con el primer estado en cero.
Partiendo de un estado de “no sincronismo”, el componente “alinea_e1” intenta encontrar la
cadena FR. Luego de esto, dispone de un contador que indica cuando ha llegado lo que debe ser
el octeto NFR y se evalúa el segundo bit del mismo. En caso de ser “1”, un contador de estados
indicará la próxima vez que se encuentre la cadena FR y la trama quedará sincronizada.
Para lo anterior se evalúan los estados de la máquina en ambas transiciones de la señal de reloj
(subida y caída). La señal de reloj en este caso es de 2 MHz, por lo que se garantiza un tiempo
suficiente para el establecimiento de los datos en las variables y señales usadas.
En caso de detectarse pérdida de sincronismo el sistema reinicia el muestreo bit a bit de los datos
de entrada, intentando encontrar las cadenas FR y NFR. Además, notifica este evento poniendo a
cero la señal de sincronismo.
En cada transición de reloj, se evalúa el estado de la señal reset. Al detectarse la activación de
esta señal (reset = 1) se restablecen los valores iniciales de las variables y señales necesarias,
para reiniciar la operación del componente.
if ( clk='1' and clk'event) then
case estado is when H => if cont_FR>504 then cont_FR:=0;
else cont_FR:=cont_FR+1; end if; if (cont_estados=6 and NFR='1') then sync<='1';
else sync<='0'; end if; when A=> if reset='1' then sync<='0';
cont_FR:=0; end if; when others => cont_FR:=0; end case;
end if;
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 52
En el fragmento de código anterior, perteneciente al componente alinea_e1, se muestra parte del
algoritmo de detección del sincronismo de las tramas E1. Este fragmento es el que sigue a
continuación de la máquina de estados, cuya operación tiene lugar con la caída del pulso de reloj.
En el estado H se entra cuando se acaba de detectar una cadena FR, tras lo cual se activa el
contador cont_FR, y se mantiene el mismo estado hasta que cont_FR alcanza el valor 505. Esta
es la cantidad de bits que hay desde la cadena FR detectada hasta el comienzo de lo que debe ser
la siguiente cadena FR. Antes, cuando el contador cont_FR alcanza el valor 250, se lee la entrada
“bits” intentando detectar la cadena NFR (C1xx xxxx). Si hay un ´1´ a la entrada se pone a 1 la
variable NFR. Pasados los 505 bits se vuelve a activar la máquina de estados, tras lo cual se sale
del estado H. Entonces, si el octeto siguiente se corresponde con la cadena FR, obligatoriamente
deberá transitarse por una serie de estados tal que un contador cont_estados tomará el valor 6.
Habiéndose cumplido esta condición, en la próxima subida del reloj se detectará el valor de este
contador y el de la variable NFR y se activará la señal de sincronismo sync (ver línea subrayada en
el código). Como se verá a continuación, el componente adq_bits está escuchando la cadena de
bits de entrada, así como la señal de reloj, pero no se activa hasta tanto no está activa la señal de
sincronismo.
Luego de detectarse un estado de alineación de tramas, otro componente VHDL (“adq_bits”) se
encarga de extraer los octetos de la transmisión serie. Para esto tiene en su estructura un puerto
de entrada para las tramas E1, uno para la señal de reloj, un puerto para reset y uno para la señal
de sincronismo. Consta además de un puerto de salida de ocho bits para los octetos, uno para la
indicación de datos listos (ready) y otro para generar una señal alarma.
ENTITY adq_bits IS
PORT (clk :in std_logic; bits :in std_logic; sync :in bit; reset :in std_logic; octeto :out std_logic_vector (7 downto 0); canal :buffer integer range 0 to 30; alarm :out std_logic_vector (0 to 0); ready :out bit); END adq_bits;
En “adq_bits” existe un contador que lleva un registro de la cantidad de octetos consecutivos cuyo
valor es cero (0000 0000) ó FF (1111 1111). Al llegar a un valor predeterminado, se dispara una
señal de alarma indicando que existe una posible falla en la transmisión, o bien el canal en
cuestión está vacío.
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 53
Este componente está constantemente recibiendo los bits de entrada al igual que “alinea_e1”.
Cuando detecta la indicación de alineación, entonces comienza a extraer los octetos del flujo serie
a la vez que los va relacionando con el canal que les corresponda. Los octetos válidos los pone en
un puerto de salida, y pone en otro puerto el canal. Luego, pone a “1” la señal ready de salida,
indicando que los datos están listos para ser tomados por la siguiente fase.
Este componente posee un contador que detecta cuando llega el canal cero del E1. Este canal no
porta datos de señalización, por lo cual no es tomado en cuenta.
La señal reset, como sucede con el componente anterior, se activa y provoca que las señales y
variables de “adq_bits” vayan a su estado inicial quedando el módulo preparado para reiniciar sus
operaciones.
Para el funcionamiento conjunto de ambos componentes, se definió un par entidad-arquitectura de
mayor jerarquía en VHDL (adq_e1_top) donde estos son instanciados. Seguidamente, la parte de
declaración de los puertos, donde se observa que las entradas-salidas de la entidad son la suma
de las de los componentes.
entity adq_e1_top is port( clkE1 :in std_logic; bits :in std_logic; reset :in std_logic; LOF_alarm :out std_logic_vector (0 to 0); octeto :out std_logic_vector (7 downto 0); canal :buffer integer range 0 to 30; alarm :out std_logic_vector (0 to 0); ready :out bit); end adq_e1_top;
Lo que sigue es un fragmento donde se realiza el mapeo de puertos entre los componentes y la
entidad superior.
AlineaE1: alinea_e1 port map( clk => clkE1, bits => bits, reset => reset, sync => sync_int, LOF_alarm => LOF_alarm);
AdqBits: adq_bits port map( clk => clkE1, bits => bits, reset => reset, sync => sync_int, octeto => octeto, canal => canal, alarm => alarm,
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 54
ready => ready);
Los componentes antes descritos se programaron en VHDL utilizando la plataforma de diseño Max
Plus II. Con esta herramienta se realizó además la compilación y la simulación del hardware. Para
esto se seleccionó en Max Plus II el EPLD EPM3128ATC100-5 de la familia MAX 3000 de Altera.
El siguiente esquema muestra la interconexión de de los componentes y sus señales de entrada-
salida.
Fig. II.3 Esquema de interconexión de componentes VHDL para la adquisición de datos
Tras tener listos y simulados los componentes de la adquisición de datos, se construyó un módulo
IP para Xilinx que integrara todas estas funciones. Se escogió el bus PLB para la conexión del
módulo IP con el microprocesador. Se diseñó teniendo dos variables de acceso externo de 32 bits
y con la posibilidad de generación de una señal de interrupción. Además de esto tiene habilitada la
opción de reset por software. En una variable de acceso externo (slv_reg0) se agrupa toda la
información que debe dar a la salida el módulo. Esta variable es de 32 bits, por lo que el primer
byte es para el octeto, el segundo para el canal correspondiente, el tercero para la alarma de fallo
en la transmisión y el cuarto byte para la alarma por pérdida de sincronismo. La segunda variable
(slv_reg1) se deja de reserva para futuras aplicaciones.
El módulo IP “adq_e1” posee en el proyecto un rango de direcciones a partir de la “cfc0 0000” y
hasta la “cfc0 ffff”, teniendo un espacio de 64 KB. El mismo se conectó al microprocesador (como
periférico esclavo) a través del bus PLB. Sus puertos “clkE1” y “bits” se establecieron como
puertos externos del sistema. La señal de interrupción se conectó a la entrada del controlador de
interrupciones con la mayor prioridad, por encima de la interrupción generada por el dispositivo
Ethernet. La transmisión de los datos tiene un mecanismo de colas y posee búferes de
almacenamiento de las tramas Ethernet por lo que puede tener demoras; sin embargo, la
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 55
adquisición de los datos es un proceso en tiempo real. Por esta razón se le otorga la mayor
prioridad.
Como parte del módulo “adq_e1” se generaron los ficheros user_logic.vhd y adq_e1.vhd. En estos
se definieron las salidas del módulo IP, el mapeo de los puertos y las condiciones para la
generación de la señal de interrupción.
Se generaron las librerías necesarias para el módulo “adq_e1”, donde se definen los parámetros y
funciones para la configuración del mismo. En el fichero “adq_e1.c” se definen las funciones para
el manejo de la interrupción. Esto se comentará en el apartado siguiente: “Procesamiento de los
datos”.
El módulo IP “adq_e1” en resumen, es capaz de asimilar un flujo E1, detectar su estado de
sincronismo y brindar a la salida cada octeto por separado y su respectivo canal, junto con una
señal de interrupción. También genera alarmas por pérdida de sincronismo y posibles averías en el
flujo de entrada de datos. Este módulo se creó en una carpeta fuera del proyecto, de manera que
está disponible para su uso en otros trabajos. En la figura se pueden observar las señales de
entrada-salida del módulo IP y su correspondencia con las señales de los componentes descritos
en VHDL.
Fig. II.4 Esquema simplificado del módulo IP adq_e1
Procesamiento software de los datos
Para programar y compilar la aplicación software se utilizó el XPS-SDK. Esta aplicación se
programó enteramente en lenguaje C++.
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 56
Al inicio de la aplicación se definen un conjunto de variables globales necesarias para la operación
del sistema, dado que varias funciones hacen uso de ellas. También se definen parámetros como
el número identificador de la Sonda, la dirección MAC de la interfaz Ethernet y la dirección base de
la SRAM donde se guardarán los datos capturados. Además se incluyen algunos ficheros de
drivers de los cuales se utilizan algunas funciones y parámetros. Se declaran los prototipos de las
funciones propias que se utilizarán y se definen las instancias de los drivers del controlador de
interrupciones y el dispositivo Ethernet. Se establece además el buffer para la transmisión de las
tramas Ethernet.
En el punto de entrada de la aplicación se hace un llamado a la función “Inicio”. Esta ejecuta
algunas tareas como la inicialización del dispositivo Ethernet y la memoria cache, la cual se habilita
también garantizando el correcto funcionamiento de la misma. Con esta función se inicializan
además algunas variables.
Luego de esto, la función principal entra en un ciclo infinito donde se pregunta en cada iteración
por el valor de la señal de reset. De estar activado el reset se ejecuta nuevamente la función
“Inicio” para restablecer los valores iniciales del sistema. En este ciclo se espera por la señal de
interrupción que indique la llegada de un octeto proveniente del módulo de adquisición de datos.
Cuando se detecta una interrupción se ejecuta el código relativo a esta y luego se regresa al ciclo
infinito esperando la próxima entrada de datos.
El esquema siguiente muestra el diagrama de flujos general de la aplicación software, donde
intervienen todas las funciones programadas y que serán detalladas en este apartado.
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 57
Fig. II.5 Diagrama de flujos general de la parte software del sistema
Función de atención de la interrupción del módulo IP “adq_e1” (Adquisición de datos)
Como se ha mencionado antes, el driver para el módulo IP “adq_e1” contiene algunas funciones
para el manejo de las interrupciones. Una de ellas es la función (ADQ_E1_Intr_DefaultHandler)
para el reconocimiento de la interrupción y que además limpia la bandera que se activa con este
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 58
evento. El contenido de esta función se copió y se implementó en otra (ADQ_E1_Intr_Handler).
Esta última se define en el fichero fuenteSS7.c, el cual constituye el código fuente de la aplicación.
Además de las funcionalidades para reconocer la interrupción y limpiar la bandera que la notifica,
se añade una subrutina que evalúa el octeto entrante. A través de la función XIntc_Connect se
establece que la función de atención a las interrupciones provocadas por el módulo IP “adq_e1”
será en lo adelante ADQ_E1_Intr_Handler.
Una vez que se recibe la señal de interrupción, si el octeto de entrada es la bandera de inicio de un
mensaje SS7 (0111 1110) y el contador de bytes del canal actual estaba vacío, entonces se fija
una variable indicando que en ese canal se comenzará a recibir un mensaje. Si por el contrario el
octeto es diferente a la bandera y la variable tiene valor ‘1’, se sobreentiende que es un dato más
de un mensaje SS7, en otro caso se desecha. De ser un nuevo byte de un mensaje, entonces se
hace un llamado a una función que elimina los ceros insertados por transparencia en la
transmisión. Luego de esto se ejecuta una función que guarda el dato en la dirección de memoria
que le corresponde del banco uno de la SRAM.
Al recibirse una bandera “0111 1110”, si el contador de bytes para ese canal es mayor que 12, se
sobreentiende que se ha tomado ya el último byte de un mensaje y está por comenzar a
transmitirse otro. El mensaje es mayor de 12 bytes, y es el que interesa al sistema, cuando es del
tipo MSU (unidad de señal de mensaje). Entonces se chequea el campo CRC y se verifica además
que el mensaje sea relativo a la inicialización ó terminación de llamadas. En caso de ser positivos
los resultados de las verificaciones se procede a enviar el mensaje mediante el dispositivo
Ethernet. Este a su vez, genera una alarma si ha habido algún problema con la transmisión.
Antes de comenzar a evaluar el byte recibido se implementa un mecanismo de alarma. Este tiene
como objetivo identificar la presencia de un canal vacío o algún posible error en uno de los canales
del flujo E1. Para esto se chequea si el byte es “0000 0000” ó “1111 1111”. En caso positivo se
lleva un conteo de esto a través de un contador que consiste en un arreglo de 31 elementos; o
sea, un contador para cada canal. Al llegar a 100 mensajes con solo ceros o unos en un mismo
canal se dispara la alarma. En caso de detectarse un valor diferente a los mencionados se reinicia
con cero el contador de alarma.
Nótese que en esta función no se verifica la posición del canal para saber si contiene o no
información de señalización. El módulo de adquisición de datos evalúa cada canal por igual (salvo
el de sincronismo) intentando detectar un mensaje de señalización. Esto permite detectar
automáticamente un cambio en el canal de señalización entre dos centrales telefónicas.
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 59
De manera general funciona así el tratamiento a los datos tomados del flujo E1. A continuación se
detallará con más profundidad cada una de las funciones involucradas en el proceso. Las
funciones aparecerán en el mismo orden que están en el código fuente de la aplicación.
Lo descrito antes puede verificarse en un fragmento del código de la función
ADQ_E1_Intr_Handler en el anexo 5.
Funciones de inicialización del sistema
Función principal
Este es el punto de entrada al sistema. En esta función se hace un llamado a la función “Inicio”
para establecer las condiciones iniciales del sistema.
Se chequea la señal de reset para reiniciar los parámetros fundamentales del sistema. Durante un
ciclo infinito se chequea la condición de reset. Cuando se detecta activada esta señal, se hace un
llamado a la función “Inicio” nuevamente. El objetivo del ciclo infinito es esperar por la interrupción
que generará el módulo de adquisición de datos.
Función Inicio
Está destinada a establecer las condiciones iniciales bajo las cuales se iniciará el sistema. Se
reinician con cero algunas variables relacionadas directamente con los canales del flujo E1. Se
inician y habilitan las memorias cache de instrucciones y de datos. A través de un llamado a la
función “Emaclite_Inicializa”, se establecen condiciones iniciales para la operación del dispositivo
Ethernet. También se inicializa el módulo de adquisición de datos (Adq_E1) y se habilita su
interrupción (ver fragmento de código a continuación). Si ocurre una falla, se devuelve un código
de error. Este código servirá para la futura gestión de alarmas que debe implementarse como parte
de la interfaz de gestión del sistema.
/* Reinicia el módulo Adq_E1 */ ADQ_E1_mReset(XPAR_ADQ_E1_0_BASEADDR);
/* Habilita la interrupción en el módulo Adq_E1 */ ADQ_E1_EnableInterrupt((void *) XPAR_ADQ_E1_0_BASEADDR);
Función Rst_canal
Aquí solo se reinician algunas variables (arreglos) que constituyen parámetros para el trabajo con
los canales de datos.
Funciones de procesamiento de datos
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 60
Funciones Borrar_ceros y Borrar_ceros2
Como se ha comentado antes, el extremo transmisor de la señalización introduce ceros en la
transmisión. Estos ceros están destinados a destruir las cadenas de seis unos (“111111”)
consecutivos que existan en el cuerpo de los mensajes para no confundirlas con la bandera de
inicio. La función Borrar_ceros detecta y elimina los ceros mencionados.
Para esto se define la variable “mask” y se le asigna al inicio el valor “1000 0000”. Seguidamente
se recorre un ciclo ocho veces haciendo un AND bit a bit entre el octeto de entrada y la variable
“mask”, la cual en cada iteración va rotando el ‘1’ hacia la derecha. Como resultado de esta
operación un contador almacena la cantidad de unos que tiene el octeto de entrada. Si la cantidad
de unos consecutivos es mayor que cinco se resetea el canal, dado que no puede haber un byte
en un mensaje transmitido con esta cantidad de unos consecutivos. Se hace en este caso un
llamado a la función Rst_canal y se le pasa como argumento el canal correspondiente.
En caso de que el número de unos contados en el octeto sumado al número de unos consecutivos
detectados al final del octeto anterior sea mayor o igual que cinco, entonces se incrementa un
contador que almacena la cantidad de ceros insertados en el octeto que se evalúa. La variable
“posic_ceros” marca la posición del(los) cero(s) insertado(s). El primer bit se corresponde con el
MSB y el octavo con el LSB. El contenido de esta variable se rota cuatro veces hacia arriba y luego
se le asigna el valor de la variable del ciclo correspondiente a la iteración en curso. De esta
manera queda en “posic_ceros” la posición del primer cero (de los insertados) detectado. El
sentido de rotar la variable cuatro bits hacia arriba es para situar en el otro nibble la posición del
segundo cero insertado, en caso de que lo hubiese. Luego de esto se limpia con cero el contador
de unos para continuar la búsqueda hasta el último elemento del ciclo.
Como se lee en el párrafo anterior y se puede comprobar en el código fuente, el algoritmo descrito
es capaz de retener la cantidad de unos consecutivos que quedan al final de un octeto y sumársela
luego a la cantidad de unos detectados al principio del octeto siguiente. De esta manera garantiza
eliminar los ceros insertados por el extremo transmisor de la señalización.
A continuación, la función Borrar_ceros evalúa la variable “posic_ceros” y hace una rotación de los
bits dentro del octeto de entrada para definitivamente eliminar los insertados. Para esto se auxilia
de otra función (Borrar_ceros2).
En un octeto cualquiera solo es posible encontrarse hasta dos ceros insertados; uno en la primera
posición (MSB) y otro en la penúltima, ó uno en la segunda posición y otro en la última (LSB).
Cuando se detectan dos ceros insertados, el algoritmo de eliminación hace un llamado a la función
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 61
Borrar_ceros2 como ya se ha mencionado. Ahora, para eliminar el segundo cero, si está en la
penúltima posición, se hace un segundo llamado a esta función. Notar que la posición del segundo
cero disminuye en uno al eliminar el primer cero. Esta vez se pasa como parámetro el valor 6 a la
función Borrar_ceros2. Como resultado se devuelve el octeto con los bits originales del mensaje
SS7 y dos bits vacíos en las posiciones menos significativas.
Borrar_ceros2 garantiza copiar todos los bits justo detrás del cero insertado. Luego copia los bits
que están delante del cero insertado. Seguidamente une mediante un “and” lógico ambas cadenas
de bits, corriendo la cadena posterior un lugar hacia adelante para eliminar la posición vacía. De
esta manera queda una posición vacía al final del octeto resultante. El algoritmo del programa va
llevando cuenta de esto y más adelante en la función Guardar_byte realiza un completamiento de
bits. El código de ambas funciones se puede consultar en el anexo 6.
Función Guardar_byte
Esta función tiene como objetivo salvar los mensajes SS7 capturados, byte a byte, en un espacio
de la memoria SRAM. Cada mensaje del tipo MSU puede tener una longitud total de hasta 278
bytes. Teniendo en cuenta que el sistema puede adquirir hasta 31 canales de señalización, es
necesario reservar un espacio de 8618 bytes (8,41 KB) para alojar todos los mensajes de
señalización completos, en caso de que coincidieran en el tiempo. Uno de los bancos de la SRAM
es suficiente para esto. Dado que el banco cero está destinado a la memoria cache y para guardar
las instrucciones y datos de la aplicación, se destinó el banco 1 para almacenar temporalmente los
mensajes SS7. Por tal razón se define una constante DIR_BASE_MSG con valor “0x84200000”,
siendo la dirección base del banco 1 de la SRAM. De esta manera se determina mediante la
instrucción dir=(u32*)(DIR_BASE_MSG+(canal*280) la dirección base que usará cada canal para
almacenar sus datos. A cada canal se destina un espacio de 280 bytes.
En el algoritmo se hace uso de dos búferes para implementar el completamiento de los huecos
que quedan en los bytes luego de eliminar los ceros que se han insertado durante la transmisión.
Además se hace uso de una variable “bits_back” que indica la cantidad de huecos que quedan en
el byte recién guardado. Esta variable indica la cantidad de bits del octeto entrante que se deben
destinar para cubrir los huecos del octeto anterior.
Primeramente el algoritmo evalúa la cantidad de ceros insertados que se detectaron en el octeto
que se está trabajando. En caso de ser un solo cero, le resta uno a la cantidad de ceros insertados
que en total han entrado al canal y le asigna este valor a bits_back. Esto garantiza no tener en
cuenta el cero detectado en el octeto actual y poner en bits_back el número correcto. Si la cantidad
de ceros insertados es dos, entonces se resta ese número a la cantidad de ceros de este tipo
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 62
detectados en el canal en cuestión. Puede verse en el código fuente que si es la primera vez que
se detectan ceros insertados, la variable bits_back toma valor cero. Esto significa que no existían
huecos en el octeto anteriormente guardado.
Para finalmente cubrir los huecos, se almacena en una variable el octeto anterior. En otra variable
se almacena el octeto actual pero rotado a la derecha, de manera tal que queden en las posiciones
menos significativas la cantidad de bits que indica bits_back. Luego se suman ambas variables y
se guarda en una de ellas el resultado que no es más que un byte completo. El valor de esta se
guarda entonces en la posición correspondiente al octeto anterior quedando cubiertas las
posiciones vacías.
Si la cantidad de ceros insertados en un canal es igual o mayor que ocho, se reajusta este valor
restando ocho. Finalmente se guarda en la localización que le corresponde el octeto actual y se
incrementa un contador que indica la cantidad de bytes que va teniendo el canal. La función
termina con una verificación de longitud del mensaje. Si este sobrepasa los 278 bytes se resetea el
canal (función Rst_canal), dado que este es el valor máximo admisible para la señalización no.7. el
código de esta función se puede observar en el anexo 7.
Función Clasificar_msg
El objetivo de esta función es determinar si el mensaje es relativo a los procesos de inicio ó
liberación de llamadas. En caso de ser positiva la verificación, la función devolverá un ‘1’ indicando
que se puede proceder a enviar dicho mensaje.
Para el interés de este diseño solo es necesario capturar los mensajes MSU, los cuales portan la
información de usuario de la señalización, entre otros datos. Además de esto, el interés es
puntualmente sobre los mensajes de tipo ISUP, pues es el estándar que se utiliza en nuestras
redes telefónicas.
Para lograr clasificar los mensajes y determinar los de interés, primero se asigna a una variable
“temp” el contenido del campo LI a través de un puntero que apunta a la zona de direcciones de
memoria que corresponde con el canal actual. Este campo tiene un valor mayor que dos cuando la
unidad de mensaje es del tipo MSU. Luego, se verifica si el campo SIO tiene el valor “0000 0101”,
lo cual indica que el mensaje es ISUP. Finalmente se verifica si el mensaje se corresponde con
uno de los que se muestran en la tabla 4.
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 63
Tabla II.2. Mensajes de inicio y liberación de llamadas
Mensaje SS7 Siglas Código
Dirección inicial IAM 0000 0001
Dirección subsecuente SAM 0000 0010
Dirección completa ACM 0000 0110
Respuesta ANM 0000 1001
Liberación REL 0000 1100
Suspensión SUS 0000 1101
Resumen RES 0000 1110
Liberación completa RLC 0001 0000
Progreso de llamada CPG 0010 1100
Función Chk_error
El campo CRC contiene un código de 16 bits que se genera en el extremo transmisor de la
señalización. Este código se genera tras una suma binaria de dos polinomios que son resultado de
algunas operaciones matemáticas donde intervienen el polinomio que representa al mensaje SS7
(sin incluir la bandera y el propio campo CRC); y un polinomio generador (Gx) que para el caso
específico de esta señalización es x16 + x12 + x5 + 1. Las operaciones mencionadas se detallan con
más profundidad en la Rec. Q.703 de la UIT-T, en su sección cuarta.
En el extremo receptor de la señalización, la cadena de bits del mensaje, incluyendo el código de
16 bits, se dividen por Gx y debe resultar un resto (Rx) para esta división de “0001110100001111”
cuando no existan errores de transmisión.
La división entre dos números binarios puede efectuarse como un OR exclusivo entre ambos. En
el caso de la SS7 se toma la cadena de bits del mensaje a partir del último bit de la bandera de
inicio e incluyendo el campo CRC, y se hace un OR exclusivo de esta con Gx. A continuación se
toma el resultado de esta división parcial, se eliminan los ceros contiguos a la izquierda y se
rellena por el extremo del LSB hasta cubrir 17 bits (como mínimo) con el resto del mensaje. Se
efectúa la misma secuencia hasta que queden 16 bits como resto de la operación.
En el algoritmo se definen dos variables de 32 bits y se les asignan los valores del polinomio
generador (Gx = 0x88108000) y el resto (Rx = 0xE8780000). A continuación, se ejecuta un ciclo
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 64
del tipo while donde se garantiza mantener una variable (trama) con más de 16 bits para poder
efectuar el OR exclusivo. Para esto se utilizan las funciones Rellenar y Busca_uno. El ciclo finaliza
cuando la variable “cont” ha alcanzado un valor igual a la cantidad de bytes del mensaje (variable
cnt_bytes[canal]), de manera que se garantiza que todos los bytes del mensaje sean computados.
En ese caso se verifica si el valor que queda en la variable trama es igual a Rx. En caso positivo
se devuelve un ‘1’ como resultado de la función indicando que no existen errores de transmisión.
De lo contrario se devuelve un cero (‘0’) con lo que se descarta el mensaje.
El conjunto de las 3 funciones que garantizan el chequeo del CRC se puede ver en el anexo 8.
Función Rellenar
Esta función está destinada a rellenar la variable trama para que pueda efectuarse la operación
OR exclusivo con cada byte del mensaje en la función Chk_error.
Aquí se define la variable “temp” para almacenar temporalmente los bytes que se pasarán a trama
posteriormente para completar un número de bits mayor que 16. Luego, se determina cuántos
bytes de la variable “trama” son cero, contados a partir del menos significativo. Este registro se
lleva en la variable n. Seguidamente, por cada byte en cero se copiará un byte del espacio de
memoria destinado al canal correspondiente y se agregará a “temp”. Esto se hace en un ciclo del
tipo for, donde los bytes copiados se van desplazando ocho lugares hacia arriba (MSB). Como
resultado en “temp” puede haber desde dos hasta cuatro bytes para rellenar trama.
La variable “rotac” indica los lugares que hay que correr a trama hacia la izquierda para eliminar
los ceros y dejar un ‘1’ como elemento más significativo. Luego, a “rotac” se le resta la cantidad de
bits que se han introducido a través del algoritmo de Rellenar. Por último se rotan los bits de
“temp” a la izquierda persiguiendo el objetivo descrito antes y se suma a trama. Esta variable
vuelve a quedar lista para la operación requerida con Gx y cuando se llegue al último byte del
mensaje y “trama” contenga menos de 17 bits en las posiciones más significativas, entonces se
compara con Rx.
Función Busca_uno
Con el algoritmo que se implementa aquí se garantiza que la cadena de bits almacenada en la
variable trama comience con ‘1’ para poder realizar la operación del OR exclusivo correctamente.
Para lograr esto se define una variable temp con valor 0x80000000. Como la misma posee un solo
‘1’ como MSB, este se rota hacia la derecha en cada iteración de un ciclo for, donde se va
comparando con el contenido de trama intentando identificar la posición del primer ‘1’. En caso de
encontrarse alguno en una de las iteraciones, se retorna la posición de este en el valor devuelto
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 65
por la función. De lo contrario se retorna el valor 32. Este indica que se recorrieron los 32 bits sin
hallar un bit diferente de cero.
En este caso debe observarse cómo en la función Chk_error se pasa a otra iteración del ciclo
while, donde se hace un nuevo llamado a Rellenar(). Debe notarse que de esta función resultará
que la variable trama sea “cargada” con cuatro nuevos bytes del contenido del mensaje SS7 que
se está trabajando. El resto sigue como se ha explicado antes.
Funciones de transmisión de datos
Función Emaclite_Inicializa
Una vez que se ha verificado que el mensaje es de interés para el sistema y que el mismo no
contiene errores de transmisión, ya se está entonces en condiciones de efectuar la transmisión de
este hacia el servidor correspondiente.
Para garantizar la transmisión vía Ethernet se hace uso del módulo XPS Ethernet Lite. El driver de
este dispositivo posee un grupo de funciones y parámetros destinados para la configuración y
puesta en marcha del mismo.
Primeramente se definen dos punteros para las respectivas instancias del dispositivo Ethernet y el
controlador de interrupciones. Los punteros se cargan con las direcciones de las instancias de
estos dispositivos definidas al inicio del programa.
Seguidamente se inicializa el XPS Ethernet Lite y se ejecuta un auto chequeo del mismo, a través
de las funciones XEmacLite_Initialize y XEmacLite_SelfTest. En ambos casos se devuelve un
código de error si ocurre alguna falla en el proceso. La función de auto chequeo básicamente
comprueba la escritura y lectura correctas en los búferes de transmisión y recepción.
Mediante la función XEmacLite_SetMacAddress se establece la dirección MAC local con que se
transmitirá la trama Ethernet. Se pasa a esta función el parámetro LocalAddress definido al inicio
del programa.
La transmisión Ethernet genera una interrupción cuando la trama ha sido enviada. Para esto se
conecta el dispositivo de red al controlador de interrupciones a través de la función
EmacLiteSetupIntrSystem. En este caso también se devuelve un código de error si ocurre algún
problema.
Los manejadores de interrupción son aquellas funciones a las que se hará un llamado luego de
ocurrido un evento de este tipo. La función XEmacLite_SetSendHandler se encarga de establecer
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 66
cuál es aquella que se ejecutará al ocurrir la interrupción. En este caso se establece
EmacLiteSendHandler como el código a ejecutar en tal caso.
Por último en esta función se habilitan las interrupciones para el módulo Ethernet Lite. Al culminar
la función Emaclite_Inicializa debe quedar totalmente listo el dispositivo como para empezar a
transmitir las tramas conteniendo los mensajes de señalización.
Función EmacLiteSendFrame
El rol de esta función es conformar la trama Ethernet que posteriormente será enviada. Aquí se
utiliza un puntero a la zona de direcciones de la memoria donde se encuentran los bytes del
mensaje que se pretende enviar, otro puntero garantiza que la trama se escriba en el búfer
TxFrame y un tercero apunta a la dirección MAC de destino que se prefijó al inicio del programa a
través de la variable “DestAddress”.
Lo primero que se hace es situar en la variable “dir” la dirección base del canal actual para tomar
los octetos del mensaje de esa ubicación. Seguidamente se pone en false una bandera que indica
el estado de una trama (si ha sido transmitida o no), preparando esta para la próxima transmisión.
Se comienza entonces a ensamblar la trama asignando al puntero “FramePtr” la dirección del
primer elemento del búfer TxFrame. Los campos Preamble y SFD son insertados automáticamente
por el driver del dispositivo Ethernet. Por lo tanto se comienza a construir la trama introduciendo
los 48 bit de la dirección MAC de destino incrementando los valores de los punteros “FramePtr” y
“AddrPtr” y pasando los valores que apunta el segundo a la ubicación que apunta el primero. De
manera análoga se introducen los valores de la dirección MAC de la Sonda; solo que estos valores
se toman directamente de la variable global “LocalAddress”.
Fig. II.6 Estructura de trama Ethernet
A continuación toca introducir la cantidad de bytes que transportará esta trama. Este dato se pasa
como parámetro de la función a través de la variable “PayLoadSize”. Este dato es de 16 bits y el
tipo de datos de FramePtr es u8 (entero sin signo de 8 bits), por lo que es necesario hacer un
cambio de tipo de dato por medio de la expresión *((u16 *)FramePtr) para añadir a la trama el dato
de la cantidad de bytes a transmitir. El valor que se pasa como parámetro a través de
“PayLoadSize” es el contenido de la variable “cnt_bytes[canal]”, donde canal se refiere al canal de
la trama E1 que se está trabajando en ese momento y ese elemento del arreglo cnt_bytes lleva
cuenta de la cantidad de octetos que tiene el mensaje SS7.
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 67
Seguidamente se introducirán octeto por octeto todo el cuerpo del mensaje almacenado en
memoria, sin tener en cuenta el campo CRC. Luego se asigna a la dirección donde apunta
FramePtr el contenido de la dirección que apunta la variable “dir”, mencionada antes. Ambos
punteros se van incrementando en cada iteración del ciclo hasta recorrer todo el espacio de
memoria donde se almacena el mensaje, de manera que todo quede transferido hacia el búfer de
transmisión.
“PayLoadSize” se restablece para incluir un número aleatorio que marca cada mensaje y para
incluir el identificador de la Sonda además. El número aleatorio se toma (en este prototipo) de un
arreglo de números creados a tal efecto. La intención es marcar cada mensaje enviado al Servidor
de aplicaciones, de manera tal que este pueda comparar la marca contra una tabla similar e
identificar que el mensaje procede efectivamente de la Sonda, comprobando que esta no ha sido
suplantada. O sea, funcionará al estilo de una tabla de saltos de frecuencias donde transmisor y
receptor tendrán la misma información para sincronizarse. El diseño de un equipo profesional
puede suponer la generación y envío de esta tabla de números hacia la Sonda desde una
aplicación software en un Servidor. La tabla debe regenerarse y reenviarse cada cierto intervalo de
tiempo.
Una vez introducidos todos los datos se hace un llamado a la función XEmacLite_Send, la cual
enviará la trama hacia el búfer que implementa el driver del XPS Ethernet Lite. Esta función coloca
la trama previamente construida en dicho búfer y activa el mecanismo para la transmisión. Este
mecanismo está regido por colas, por lo que pueden almacenarse varias tramas en espera de ser
enviadas. Si ocurre alguna falla en la ejecución de esta función se genera una alarma mediante la
variable “alarma_tx”.
El dispositivo Ethernet está configurado para que opere en modo de interrupción. Por tanto,
cuando termine de enviar la trama dará una señal y ejecutará una función de retorno. Además de
esto se ejecutará la función EmacLiteSendHandler que se definió antes.
El fragmento de código que se muestra en el anexo 9 corresponde a la conformación de la trama
Ethernet. Cuando se va a insertar la carga útil en la trama (un mensaje SS7), se accede a la
memoria externa mediante un puntero (*dir) que tiene la dirección donde este mensaje se
encuentra. Notar como los últimos 3 octetos son un identificador del mensaje para garantizar
integridad y un identificador del equipo que envía la información al servidor.
Función EmacLiteSendHandler
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 68
Esta función se ejecuta como una función de retorno de la interrupción. En ella solo se activa la
bandera “TransmitComplete” indicando el éxito de la operación de transmisión. Además se
incrementa un contador “cont_msg_tx” que lleva la estadística de la cantidad de mensajes
transmitidos satisfactoriamente. Como contrapartida de este contador se implementa en la función
de retorno de la interrupción generada por la adquisición de datos, un contador de mensajes
enviados (“cont_msg_env”). Evidentemente la diferencia entre estos valores indicará la cantidad de
mensajes perdidos. Esta estadística, así como la gestión de las alarmas en general, son
cuestiones a implementar en la segunda fase de desarrollo del proyecto, como se describe en la
Tarea técnica.
Función EmacLiteSetupIntrSystem
Dado que los dispositivos Adq_e1 y XPS Ethernet Lite generan interrupciones, es necesario
configurar un manejador para estos eventos. Se necesita conectar el driver de cada uno de estos
dispositivos al controlador de interrupciones (XPS INTC) para que este último gestione las
peticiones de interrupción al microprocesador.
Primeramente en el código se inicializa el driver del controlador de interrupciones a través de la
función XIntc_Initialize. Seguidamente, mediante la función XIntc_Connect se establecen los
manejadores de la interrupción, los cuales se ejecutarán cada vez que ocurra un evento de este
tipo. Notar en el código fuente que se invoca la función XIntc_Connect primeramente para conectar
al Adq_e1 y luego se vuelve a llamar para conectar a XPS Ethernet Lite.
Finalmente se inicia el XPS INTC en modo real y se habilitan en este dispositivo la interrupción
para el XPS Ethernet Lite y el Adq_e1.
Se muestra a continuación un fragmento del código donde se conectan las subrutinas de manejo
de las interrupciones.
/* Conecta la subrutina para la interrupción en EmacLite */ Status = XIntc_Connect(IntcInstancePtr, EmacLiteIntrId, XEmacLite_InterruptHandler, (void *)(EmacLiteInstPtr));
if (Status != XST_SUCCESS) return XST_FAILURE;
/* Conecta la subrutina para la interrupción en Adq_E1 */ Status = XIntc_Connect(IntcInstancePtr, AdqE1IntrId, ADQ_E1_Intr_Handler, NULL);
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 69
Capítulo III. Comprobación de resultados
Introducción
Este capítulo se centrará en la comprobación de los resultados obtenidos durante las pruebas de
operación del prototipo diseñado. A lo largo del capítulo podrán observarse las modificaciones
introducidas al diseño del prototipo en aras de verificar el correcto resultado de su operación.
Debe recordarse que nuestro sistema opera a partir de un flujo E1 portador de 31 canales de
señalización no. 7 como entrada de datos, además requiere de una señal de reloj para sincronizar
el flujo de entrada de bits. A los efectos de la comprobación del diseño resulta en extremo difícil
conseguir la aprobación del uso de un flujo E1 de ETECSA. Tampoco contamos con un generador
de señalización como fuente de entrada de datos.
Por lo anterior, para la comprobación de la operación del prototipo diseñado se evaluaron algunas
variantes. Primeramente se evaluó la posibilidad de simular el diseño mediante el software
ModelSim, lo cual no fue posible debido a que el módulo IP clock_generator solo permite ser
simulado mediante el software NCSim. La mayoría de los componentes del diseño dependen de
las señales del clock_generator.
Además, se evaluó la utilización de la plataforma virtual que posee el EDK para emular las tarjetas
de evaluación de FPGA. Sin embargo, esta funcionalidad no permite el uso de la versión 7 del
procesador MicroBlaze y tampoco permite el uso del bus PLB. Estas características están
presentes en el diseño del prototipo, por lo cual no fue posible el uso de la plataforma virtual.
Por último se decidió introducir modificaciones al diseño, tanto en la infraestructura HW como en la
aplicación software, para generar algunos patrones de mensajes SS7 que sirvieran como entrada
de datos a las funciones de procesamiento y transmisión. A través de algunos segmentos del
código fuente de la aplicación, se demostrarán los resultados obtenidos.
Como se mencionó en el capítulo anterior, los componentes HW para la adquisición de datos se
programaron en VHDL con Max Plus II. Haciendo uso de este mismo software se generaron las
señales de entrada necesarias efectuando la simulación de los componentes que posteriormente
conformaron el módulo IP “Adq_E1”. Este software se escogió debido a las facilidades que brinda
su entorno de simulación.
III.1 Simulación de la etapa de adquisición de datos
Para la adquisición de datos se diseñaron en Max Plus II dos componentes en lenguaje VHDL:
alinea_E1 y adq_bits. El primero de ellos garantiza el reconocimiento de la alineación de las
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 70
tramas E1 en el flujo de entrada, notificando mediante una señal cuando se alcance esta condición
de alineamiento. El segundo componente espera a ser notificado por el primero tras detectarse
tres tramas correctamente alineadas y comienza este a conformar los octetos con los bits
entrantes en serie los sitúa en una salida en paralelo junto con el número del canal
correspondiente.
La comprobación de los componentes se realizó de manera separada aunque con los mismos
patrones de bits, en tanto ambos tienen como entrada las mismas señales, exceptuando la señal
de notificación de alineación (“sync”). Esta señal la brinda alinea_E1 a la salida, y es una de las
entradas de adq_bits. Se utilizó una señal de reloj de 2 Mbps para emular el reloj de sincronismo
de un flujo E1.
Para simular la detección de alineación de tramas se generaron tres patrones diferentes.
Primeramente se utilizó un patrón de bits (señal de entrada “bits”) donde se observan tres tramas
cuyos octetos de sincronismo son correctos, y por consiguiente provocan, al cabo de la tercera
trama la activación de la señal de alineación (“sync”). A continuación se observa una secuencia
gráfica de la detección de los octetos FR-NFR-FR. Nótese cómo al cabo de los 2,1us se lee el
último bit de un octeto FR, con lo cual se prepara el componente para un posible estado de
alineación. En este punto se activa un contador (“cont_FR”) que permitirá que al cabo de 250
pulsos de reloj se verifique si se recibió un octeto NFR
Fig. III.1 Detección de un octeto FR (x001 1011) por primera vez a los 2,1us
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 71
Fig. III.2. Detección de un octeto NFR (x1xx xxxx)
Fig. III.3. Detección de un octeto FR e indicación de estado de alineación
Como se puede observar en la figura 13, se detectó un octeto del tipo NFR en el canal cero de la
segunda trama generada. La señal “NFR.Q” que se observa es una bandera indicando que se
cumplió este requerimiento.
La figura 14 muestra cómo al cabo de los 104,5us se detecta el último bit de un octeto FR en la
tercera trama generada. Tras esta condición se alcanza un estado de alineación de tramas, lo cual
es marcado en el gráfico de la simulación mediante la activación de la señal sync tras 100ns.
Nótese cómo se reinicia el contador de bits, para rastrear nuevamente la palabra NFR y repetir el
ciclo de detección. A partir de aquí, el componente adq_bits puede comenzar a agrupar los bits en
octetos.
El segundo patrón de bits correspondiente a la comprobación de alinea_E1, se diseñó de manera
que no se alcanzara el sincronismo, con el objetivo de observar el comportamiento de la señal
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 72
“LOF_alarm”. Esta señal notifica la pérdida de alineación en el flujo de entrada; y se activa cuando
transcurrió una trama completa más un octeto (262 octetos) en este estado. Nótese en la figura 15
cómo al cabo de los 52,5us se genera la señal de alarma. Esta condición no detiene el
funcionamiento del componente; el cual sigue evaluando el flujo de bits intentando detectar tramas
alineadas. La gestión de las señales de alarma es uno de los objetivos de la segunda fase del
desarrollo del sistema de monitoreo.
Fig. III.4. Generación de señal de alarma por pérdida de sincronismo
El último patrón que se utilizó para la comprobación del componente alinea_E1 persiguió el
objetivo de verificar el comportamiento del diseño ante la generación de la señal reset. En este
caso se provocó antes un estado de alineación de tramas, con lo cual se activa la señal sync.
Posteriormente se aplica una señal de reset para llevar al HW a su estado inicial. Como se
observa en la figura 16 algunos contadores y la señal “estado” regresan a su situación inicial. Esto
permite que la máquina de estados se prepare para la detección de próximas tramas alineadas. La
señal de alineación consecuentemente también cae a cero.
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 73
Fig. III.5. Activación de señal de reinicio
El otro componente que interviene en el proceso de adquisición de datos es adq_bits. Para la
simulación de este componente se empleó un patrón de bits correspondiente con una transmisión
de tramas alineadas. Esto es imprescindible, ya que adq_bits solo trabaja mientras se detecte
alineación en el flujo E1 de entrada. En el gráfico obtenido durante la simulación (figura 17) se
observa la señal de entrada sync. Esta es una señal de salida del componente antes visto y aquí
se evalúa su estado para definir la lectura o no de la señal de entrada bits, contenedora de la
información de señalización.
El contador “cnt_sync” que se observa en el gráfico garantiza que solo se lean los bits que siguen
al canal cero del flujo E1, en tanto son estos los contenedores de información de señalización.
Obsérvese como al cabo de 1us comienza a leerse el octeto ‘00001111’, teniendo en cuenta que
se transmite el LSB primero. La señal “ready” se activa un instante después de leer el último bit del
octeto. Esta señal está en ‘1’ durante un período de reloj indicando que existe un octeto y su canal
correspondiente listos a la salida para ser leídos. Como se mencionó en el capítulo anterior, la
activación de la señal “ready” genera una interrupción en el módulo IP concebido para la
adquisición de la señalización SS7.
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 74
Fig. III.6. Delimitación de octetos dentro del flujo E1
El componente adq_bits también genera una alarma si detecta 32 octetos consecutivos cuyo valor
sea ‘00000000’ ó ‘11111111’. Para comprobar el funcionamiento de esta característica se generó
una secuencia de bits con todos en cero. El gráfico de la simulación muestra en la figura 18 el
resultado obtenido. Nótese que la generación de esta alarma no detiene el funcionamiento del
componente. Esta alarma puede ser muy importante ya que puede alertar sobre el cambio de un
canal de señalización o un enlace caído, tal como la alarma reiterada por pérdida de sincronismo.
Fig. III.7. Generación de alarma por posible fallo en el enlace de señalización
III.2 Comprobación de la etapa de procesamiento de datos
Los módulos de procesamiento y transmisión de datos se componen de varias funciones
programadas en C++ que constituyen el proyecto SDK. Además, la transmisión Ethernet se
soporta fundamentalmente sobre el módulo IP XPS_Ethernetlite. Estas cuestiones fueron
abordadas con detalles en el capítulo anterior.
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 75
Tras la compilación exitosa del prototipo diseñado mediante las herramientas EDK y SDK de Xilinx,
se realizaron algunas modificaciones en el diseño con el objetivo de generar las señales
necesarias para su comprobación sobre una tarjeta de evaluación. Se eliminó de la infraestructura
HW el módulo IP “adq_e1”. Este módulo requiere de señales externas, las cuales fueron
generadas mediante una función programada como parte del mismo sistema. Se añadieron dos
módulos del tipo GPIO para atender los botones y la lámpara de 7 segmentos de la tarjeta de
evaluación. Ambos periféricos intervienen en la generación de patrones y visualización de los
resultados respectivamente.
Se generaron tres patrones de datos diferentes para evaluar el comportamiento del prototipo. Dos
de los patrones generados provocan un error equivalente a la no aceptación del mensaje, lo cual
se visualiza mediante una letra E en la lámpara de 7 segmentos. El otro patrón es aceptado como
un mensaje válido y se muestra un 7 en la lámpara. Cada patrón de datos es generado tras ser
pulsado un botón.
A la función main del proyecto SDK se le introdujo un segmento de código (se muestra al final del
párrafo) destinado a la lectura de los botones. Como se puede observar, estos son leídos dentro
de un ciclo condicionado por la variable reset, cuyo valor no cambia durante estas pruebas, lo que
convierte al ciclo en infinito. Pulsar el botón de la derecha (botón 1) provoca que la variable octeto
tome el valor cero. En este caso se genera un mensaje cuyo contenido es nulo. El botón siguiente
provoca la generación de un mensaje cuyos octetos son siempre ceros y unos alternados
(‘01010101’). El último botón hace que se genere un mensaje cuyos octetos tienen todos la forma
‘01110111’. Todos los valores que toma la variable octeto provocan diferentes respuestas a lo
largo del código de la aplicación. Este segmento termina haciendo un llamado desde dentro del
ciclo a la función Construye_msg.
while (reset != TRUE){ data=XGpio_mReadReg(XPAR_PUSHBUTTONS_BASEADDR,XGPIO_DATA_OFFSET); switch (data) { case 0x00000001: octeto = 0; //botón 1 (derecho) case 0x00000002: octeto = 0x55; //botón 2 case 0x00000003: octeto = 0x77; //botón 3 break; default: octeto = 0xFF; } if (octeto != 0xFF) Construye_msg(); }
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 76
La función Construye_msg es quien envía los octetos hacia donde estos serán procesados.
Primeramente se hace un llamado a la función ADQ_E1_Intr_Handler dónde se pasa como
parámetro la constante bandera, definida como 0x7E (primer octeto de un mensaje SS7). Esta
función no posee aquí el código de tratamiento de la interrupción como en la aplicación original,
pero mantiene el resto de su funcionalidad para la evaluación de los octetos entrantes.
Posteriormente en la función Construye_msg (al final del párrafo) se evalúa si el valor del octeto
generado previamente corresponde al patrón de un mensaje aceptable o no. En este caso la
variable i toma el valor de la cantidad de octetos que conformarán el mensaje de prueba. Si el
valor de la variable octeto es 0x77 (botón 3) se sobrepasa el máximo número de bytes para un
mensaje de señalización haciendo i = 250; de lo contrario se fija un total de 15 bytes para el
mensaje. Se ha cambiado aquí el valor 278 por 250 como máxima cantidad de bytes en un
mensaje SS7, para definir i como “unsigned int” de 8 bits. Luego de esto se entra en un ciclo donde
se envía i veces el valor del octeto generado antes a la función ADQ_E1_Intr_Handler como
cuerpo del mensaje de prueba. Finalmente se envía la bandera 0x7E para cerrar el mensaje.
void Construye_msg() { u8 temp, i; temp = octeto;
ADQ_E1_Intr_Handler(bandera);
if (temp != 0x77) i = 15; else i = 250;
do { ADQ_E1_Intr_Handler(temp); i--; } while (i);
ADQ_E1_Intr_Handler(bandera); }
El botón 1 provoca un mensaje vacío. Luego, al ejecutarse la función Clasificar_msg lee un cero en
el campo LI (mensaje FISU), por lo que considera este mensaje como no aceptable (no MSU). El
valor de retorno de Clasificar_msg es cero entonces y provoca que se obvie el llamado a las
funciones de transmisión de datos; y se muestra en la lámpara de 7 segmentos una indicación de
error (cuerpo del último else del código). Se muestra el mensaje de error también si ocurre un fallo
en la transmisión Ethernet. El prototipo en su diseño original cuenta con una protección que genera
una alarma cuando detecta un número determinados de octetos vacíos consecutivos en cualquier
canal. Se muestra a continuación un segmento del código de la función ADQ_E1_Intr_Handler.
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 77
if (Clasificar_msg()) { do { data2 = XGpio_mReadReg(XPAR_PUSHBUTTONS_BASEADDR,
XGPIO_DATA_OFFSET); XGpio_mWriteReg(XPAR_LED_7SEGMENT_BASEADDR, XGPIO_DATA_OFFSET, 0x00000FFF); //borrar LCD XGpio_mWriteReg(XPAR_LED_7SEGMENT_BASEADDR, XGPIO_DATA_OFFSET, 0x0000049E); //mostrar "5" } while (data2 != 0x00000002)
m_result = EmacLiteSendFrame (&EmacliteInstance, cnt_bytes[canal], DestAddress); if (m_result != XST_SUCCESS) { alarma_tx++;
XGpio_mWriteReg(XPAR_LED_7SEGMENT_BASEADDR,XGPIO_DATA_OFFSET, 0x00000FFF); //borrar LCD
XGpio_mWriteReg(XPAR_LED_7SEGMENT_BASEADDR,XGPIO_DATA_OFFSET, 0x00000617); //error si falla la Tx
} else cnt_msg_env++; }else{ XGpio_mWriteReg(XPAR_LED_7SEGMENT_BASEADDR,XGPIO_DATA_OFFSET,
0x00000FFF); //borrar LCD XGpio_mWriteReg(XPAR_LED_7SEGMENT_BASEADDR,XGPIO_DATA_OFFSET,
0x00000617); //msg. no aceptado en Clasificar_msg}
El botón 2 provoca la generación de un mensaje con 15 octetos, el cual se ha previsto que sea
aceptado por la etapa de procesamiento de la aplicación como un mensaje del tipo MSU. En la
función Clasificar_msg se verifica que el campo LI del mensaje sea mayor que 2 para garantizar
que sea un mensaje MSU. Así mismo se comprueba que el campo SIO sea 0101, lo cual indica
que es un mensaje del tipo ISUP. Ambas condiciones se cumplen satisfactoriamente en el patrón
de bits generado para el segundo mensaje de prueba (‘01010101’). También se comprueba en
esta función si el tipo de mensaje es relativo a las etapas de inicio o liberación de llamadas. En
este caso se hizo una adecuación al código de la función Clasificar_msg, añadiendo el patrón de
bits generado como un tipo de mensaje válido.
Tras ejecutarse enteramente el código de la función Clasificar_msg y validarse el patrón generado
como un mensaje correcto, se mostrará en la lámpara de 7 segmentos el número 5. Luego, se
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 78
esperará a que se presione nuevamente el botón 2 para pasar a ejecutar las funciones de
transmisión de datos. Obsérvese esto en el ciclo do-while del segmento de código anterior.
Cuando se presiona el tercer botón se genera un mensaje con una cantidad de octetos
(‘01110111’) que supera el máximo aceptado para la señalización no. 7. Debe recordarse que se
modificó el valor máximo, como se mencionó anteriormente. En la función Guardar_byte se lleva
un conteo de la cantidad de octetos almacenados por cada canal. Como se muestra en el
segmento de código al final del párrafo, luego de guardar el octeto en memoria se incrementa el
contador. Seguidamente se verifica si la cantidad almacenada supera el valor máximo, en cuyo
caso se muestra en la lámpara de 7 segmentos una notificación de error (letra E). Posteriormente
se reinician algunas variables que contienen información relativa al canal actual a través de la
función Rst_canal.
*dir = octeto; cnt_bytes[canal]++;
if (cnt_bytes[canal] > 249) { XGpio_mWriteReg(XPAR_LED_7SEGMENT_BASEADDR, XGPIO_DATA_OFFSET, 0x00000FFF); //borrar LCD XGpio_mWriteReg(XPAR_LED_7SEGMENT_BASEADDR, XGPIO_DATA_OFFSET, 0x00000617); //mostrar msg. Error ("E") Rst_canal(canal); // La MSU no puede superar los 278 bytes }
III.3 Comprobación de la etapa de transmisión de datos
Las señales de transmisión y recepción de datos del dispositivo Ethernet (hacia y desde la capa
física, respectivamente) se conectaron a cuatro pines de uno de los puertos de expansión de una
tarjeta Spartan 3 Starter Kit. Ver fichero system.ucf en la carpeta digital del proyecto. Se hizo esta
asignación dada la no existencia de un conector RJ-45 en la tarjeta disponible. De haber existido
los recursos necesarios, hubiese sido idóneo el uso de un software para capturar las tramas
Ethernet generadas durante la comprobación del prototipo.
A pesar de esto, para la verificación de las funciones de transmisión Ethernet se seleccionaron dos
estrategias. En primer lugar se garantizó que al inicializar el dispositivo Ethernet se efectuara un
auto chequeo del mismo. La función XEmacLite_SelfTest asegura que lo que se escribió en el
búfer de transmisión sea leído íntegramente por otra función. De no coincidir los datos de escritura
y lectura se retorna un error y provoca salir del programa. Con esto se comprueban la inicialización
correcta del dispositivo, así como la correcta disponibilidad del búfer de transmisión. La aplicación
Capítulo III
Diseño de un sistema para el monitoreo de la señalización no.7 79
original del diseño efectúa este auto chequeo como parte de la comprobación inicial de todos los
componentes. Véase en el código a continuación.
Result = XEmacLite_Initialize(EmacInstancePtr,EMACLITE_DEVICE_ID); if (Result != XST_SUCCESS){ return ++ErrorCnt; }
Result = XEmacLite_SelfTest(EmacInstancePtr); if (Result != XST_SUCCESS){ return ++ErrorCnt; }
Como medida complementaria se introdujo una pequeña modificación a la función de atención de
la interrupción del driver del dispositivo Ethernet. Esta consistió en mostrar un número 7 en la
lámpara de la tarjeta en el caso de ejecutarse tal función. A saber, cuando se hace un llamado a la
función XEmacLite_Send, como parte de la etapa de transmisión, esta sitúa en el búfer de
transmisión una trama ya elaborada con su carga útil (datos a transmitir) más un encabezado. Si el
dispositivo Ethernet está configurado para operar con interrupciones, cuando se tome del búfer la
trama y se transmita a la capa física, se genera una interrupción y se ejecuta luego la función
EmacLiteSendHandler. Luego, se tiene la certeza de que ocurrió la transmisión si se muestra la
indicación en la lámpara como se mencionó antes. Debe recordarse que para que tenga lugar esta
comprobación debe pulsarse el botón 2, tras lo cual se mostrará un número 5 en la lámpara. Luego
de esto se pulsa nuevamente el botón 2 y ocurre la transmisión y la respectiva notificación.
Obsérvese seguidamente la función de atención a la interrupción del driver EmacLite.
static void EmacLiteSendHandler(void *CallBackRef) { XEmacLite *EmacLiteInstPtr; EmacLiteInstPtr = (XEmacLite *)CallBackRef;
TransmitComplete = TRUE;
XGpio_mWriteReg(XPAR_LED_7SEGMENT_BASEADDR, XGPIO_DATA_OFFSET, 0x00000FFF); //borrar LCD
XGpio_mWriteReg(XPAR_LED_7SEGMENT_BASEADDR, XGPIO_DATA_OFFSET, 0x000001FB); //mostrar "7"
cont_msg_tx++;
return; }
Conclusiones
Diseño de un sistema para el monitoreo de la señalización no.7 80
Conclusiones
A lo largo de este trabajo se ha hecho un estudio del contexto donde se ubica un sistema de
monitoreo de la señalización no.7. Como parte del estudio se recorrieron varios aspectos
generales de la SS7, del impacto negativo del fraude en las telecomunicaciones y las tecnologías
que existen para combatirlo. Se hizo un análisis detallado, en la medida en que la información
disponible lo permitió, del estado del arte de las sondas. Esto permitió conocer y comparar algunas
estructuras y tecnologías de diseño de este equipamiento.
Para el desarrollo del sistema se estudió a profundidad la tecnología de diseño con FPGA de
Xilinx. Se verificó que los dispositivos FPGA, así como las herramientas y tarjetas de evaluación
del fabricante permitían desarrollar un sistema como el que se había propuesto con la
funcionalidad requerida.
Cabe señalar que se obtuvieron buenos resultados durante el desarrollo del trabajo, aunque no fue
posible abarcar por completo las tareas propuestas. Al respecto se detalla lo siguiente:
� Se logró desarrollar y simular con buenos resultados un módulo hardware para la
adquisición de un flujo de datos binarios de 2Mbps
� Se logró desarrollar un SoC que cumple con los requerimientos de la primera fase de
desarrollo, contemplando las funciones para el procesamiento de los datos de entrada y la
transmisión de mensajes SS7 sobre Ethernet hacia una computadora
� Se diseñaron un conjunto de pruebas para determinar el correcto funcionamiento del
sistema, aunque no fue posible implementarlas dada la poca capacidad de la tarjeta
disponible (Spartan 3 Starter Kit con FPGA de 400 mil compuertas)
� No fue posible contar con un generador de mensajes de señalización para comprobar el
módulo de adquisición de datos más allá de la etapa de simulación de este
Recomendaciones
Diseño de un sistema para el monitoreo de la señalización no.7 81
Recomendaciones
� Implementar las pruebas del capítulo III en un dispositivo cuya capacidad permita
descargar el sistema en su totalidad
� Comprobar el funcionamiento del sistema con la utilización de mensajes SS7 auténticos
� Escalar a transmisiones sobre TCP/IP para el envío de los datos al servidor
� Realizar análisis de temporización de la parte de procesamiento de datos con el objetivo
de determinar la capacidad de flujos de entrada que soporta el sistema
� Convertir las funciones críticas (tareas software) en cuanto a consumo de tiempo en
módulos IP (hardware) para mejorar el desempeño del sistema
� Ejecutar las tareas previstas en los requerimientos de la segunda fase de en aras de dotar
al sistema de mayores capacidad y prestaciones
Bibliografía
Diseño de un sistema para el monitoreo de la señalización no.7 82
Bibliografía
1. CFCA. “Announces results of worldwide telecom fraud Surrey”, junio de 2009
http://www.cfca.org/pdf/survey/2009%20Global%20Fraud%20Loss%20Survey-Press%20Release.pdf
2. “Kaspersky advierte que el 'phishing' relacionado con 'World of Warcraft' se vuelve impecable", abril de 2010
http://www.hoytecnologia.com/noticias/Kaspersky-advierte-phising-relacionado/168458
3. Sección de análisis, junio de 2011
http://www.viruslist.com/sp/analysis?pubid=207271130
4. Kaspersky, Eugene: “Panorama sobre el malware a nivel mundial”, Conferencia, Hotel Nacional, La Habana, noviembre del 2005
5. Llanes Solá, Ana Caridad: "Estrategia Antifraude en las Redes de Próxima Generación en ETECSA”, Tesis de Maestría, CUJAE, La Habana, 2005
6. UIT-T, Recomendación G.703 http://www.itu.int
7. ECTEL: “FraudView User’s Guide”, 2006
8. Subex Azure: “SAFMS Solution Overview”, noviembre del 2008
9. UIT-T, Recomendación Q.700 http://www.itu.int
10. NEC Corporation: “Sistema de Señalización No. 7. (Generalidades)”, Edición 4ta, junio del 1992.
11. UIT-T, Recomendación Q.702 http://www.itu.int
12. UIT-T, Recomendación Q.703 http://www.itu.int
13. UIT-T, Recomendación Q.704 http://www.itu.int
14. http://gsdc.epa.ericsson.se/egs/homes/epasund/C7Help.htm
15. http://www.rad.com/10/Signaling_Monitoring_Probe/2642
16. http://www.cibertec.com
17. http://www.teknotelecom.com
18. Sánchez Segura, Simón: “Presentación de la Sonda NSTS”, Conferencia, Lonja del Comercio (Sede de Alcatel S.A), La Habana, septiembre de 2007
19. http://www.rediris.es/rediris/boletin/66-67/ponencia7.pdf
20. LIMS Lightweight IP Measurement System
Bibliografía
Diseño de un sistema para el monitoreo de la señalización no.7 83
http://www.tecsidel.es
21. Xilinx Inc.: “Platform Studio User Guide”, 2006
22. Xilinx Inc.: “MicroBlaze Processor Reference Guide”, enero del 2008
23. http://www.support.xilinx.com/edk
24. Cabrera, Alejandro: “Diseño de Sistemas Empotrados con FPGA de Xilinx”, Conferencia, CUJAE, La Habana, febrero del 2007
Otras webs consultadas
1. UIT-T, Recomendación Q.763 http://www.itu.int
2. UIT-T, Recomendación Q.762 http://www.itu.int
3. UIT-T, Recomendación Q.764 http://www.itu.int
4. Gama de productos 5View 5. http://www.iberforce.com
6. http://www.support.xilinx.com/microblaze/
7. UIT-T, Recomendación G.704 http://www.itu.int
8. http://www.cisco.com/en/US/docs/internetworking/technology/handbook/Ethernet.html
9. http://www.interfacebus.com
10. http://www.icoptech.com
Diseño de un sistema para el monitoreo de la señalización no.7 84
Anexo 1
Tabla de mensajes ISUP (fragmento)
Tipo de mensaje Código Dirección completa 0 0 0 0 0 1 1 0 Respuesta 0 0 0 0 1 0 0 1 Transporte de aplicación 0 1 0 0 0 0 0 1 Bloqueo 0 0 0 1 0 0 1 1 Acuse de bloqueo 0 0 0 1 0 1 0 1 Progresión de la llamada 0 0 1 0 1 1 0 0 Bloqueo de grupo de circuitos 0 0 0 1 1 0 0 0 Acuse de bloqueo de grupo de circuitos 0 0 0 1 1 0 1 0 Indagación sobre grupo de circuitos (uso nacional) 0 0 1 0 1 0 1 0 Respuesta a indagación sobre grupo de circuitos (uso nacional)
0 0 1 0 1 0 1 1
Reinicialización de grupo de circuitos 0 0 0 1 0 1 1 1 Acuse de reinicialización de grupo de circuitos 0 0 1 0 1 0 0 1 Desbloqueo de grupo de circuitos 0 0 0 1 1 0 0 1 Acuse de desbloqueo de grupo de circuitos 0 0 0 1 1 0 1 1 Información sobre tasación (uso nacional) 0 0 1 1 0 0 0 1 Confusión 0 0 1 0 1 1 1 1 Conexión 0 0 0 0 0 1 1 1 Continuidad 0 0 0 0 0 1 0 1 Petición de prueba de continuidad 0 0 0 1 0 0 0 1 Facilidad 0 0 1 1 0 0 1 1 Facilidad aceptada 0 0 1 0 0 0 0 0 Rechazo de facilidad 0 0 1 0 0 0 0 1 Petición de facilidad 0 0 0 1 1 1 1 1 Transferencia hacia delante 0 0 0 0 1 0 0 0 Petición de identificación 0 0 1 1 0 1 1 0 Respuesta de identificación 0 0 1 1 0 1 1 1 Información (uso nacional) 0 0 0 0 0 1 0 0 Petición de información (uso nacional) 0 0 0 0 0 0 1 1 Dirección inicial 0 0 0 0 0 0 0 1 Acuse de establecimiento de bucle (uso nacional) 0 0 1 0 0 1 0 0 Prevención de bucle 0 1 0 0 0 0 0 0 Gestión de recursos de red 0 0 1 1 0 0 1 0 Sobrecarga (uso nacional) 0 0 1 1 0 0 0 0 Paso de largo (uso nacional) 0 0 1 0 1 0 0 0 Información antes de la liberación 0 1 0 0 0 0 1 0 Liberación 0 0 0 0 1 1 0 0 Liberación completada 0 0 0 1 0 0 0 0 Reinicialización de circuito 0 0 0 1 0 0 1 0 Reanudación 0 0 0 0 1 1 1 0
Diseño de un sistema para el monitoreo de la señalización no.7 85
Anexo 2
Estructura de un mensaje ISUP
Tomada de la Rec. Q 763 de la UIT-T
Diseño de un sistema para el monitoreo de la señalización no.7 86
Anexo 3
Secuencia de intercambio de mensajes en una llamada ISUP
Tomada de: NEC Corporation; “Sistema de Señalización No. 7. (Generalidades)”
Diseño de un sistema para el monitoreo de la señalización no.7 87
Anexo 4
Diagrama del hardware del proyecto
Generado por la herramienta XPS de Xilinx y modificado por el autor
Diseño de un sistema para el monitoreo de la señalización no.7 88
Anexo 5
Fragmento de la función de tratamiento de los datos recibidos por el flujo E1
void ADQ_E1_Intr_Handler() ……/* Genera alarma por posible fallo en un canal */
if (octeto == 0x00 || octeto == 0xFF){ cnt_alarma_ch[canal]++; if (cnt_alarma_ch[canal] == 100) { alarma_ch = 128 + canal; cnt_alarma_ch[canal] = 0; } else { alarma_ch = 0; } }else{ cnt_alarma_ch[canal] = 0; alarma_ch = 0; }
/* Evaluación de los octetos entrantes */
if ((octeto == 0x7E) && (cnt_bytes[canal] == 0)) { flag[canal] = 1; }else if ((octeto != 0x7E) && (flag[canal] == 1)) { octeto = Borrar_ceros(); if (octeto != 255) { Guardar_byte(); } }else if (octeto == 0x7E && cnt_bytes[canal] > 12) // Solo MSU { if (Clasificar_msg() && Chk_error()) { /* Enviar msg. a buffer de Tx */ m_result = EmacLiteSendFrame (&EmacliteInstance,cnt_bytes[canal],DestAddress);……
Diseño de un sistema para el monitoreo de la señalización no.7 89
Anexo 6
Funciones para eliminación de los ceros de tranparencia
u8 Borrar_ceros()
{
u8 i, mask, cnt_unos = 0;
posic_ceros = 0; mask = 0x80; // 1000 0000 B
/* Determina posición de ceros insertados */ for (i = 0; i < 8; i++) { mask >>= i; if (octeto & mask != 0) { cnt_unos++; if (cnt_unos > 5) { Rst_canal(canal); return (255); //255 es inadmisible para un octeto } } else if (back_unos[canal] + cnt_unos == 5) { ceros[canal]++; posic_ceros *= 16; //Corre el byte 4 lugares hacia arriba posic_ceros += ++i; //MSB es posición 1, LSB es posic. 8 cnt_unos = 0; back_unos[canal] = 0; } else if (back_unos[canal] + cnt_unos > 5) { Rst_canal(canal); return (255); } else { cnt_unos = 0; back_unos[canal] = 0; } }
back_unos[canal] = cnt_unos;
/* Rota octeto para eliminar ceros insertados */
/* Si hay 2 ceros, el 2do está en posic. 7 u 8. * En posic. 8 no se rota octeto; en 7 (ahora 6) sí */
Diseño de un sistema para el monitoreo de la señalización no.7 90
if (posic_ceros > 0) { octeto = Borrar_ceros2(posic_ceros); if (!(posic_ceros & 0x08 != 0) && (posic_ceros>16)) { octeto = Borrar_ceros2(6); } }
return (octeto);
}
-----------------------------------------------------------------
u8 Borrar_ceros2(u8 posicion)
{
u8 buffer1, buffer2;
if (posicion > 16) posicion /= 16;
buffer1 = 0xff; // Equivalente buffer1 <<= (8-posicion); // a buffer1--; // buffer1=2(8-posicion)-1 buffer1 &= octeto; octeto -= buffer1; buffer1 *= 2; octeto += buffer1;
return(octeto);
}
Diseño de un sistema para el monitoreo de la señalización no.7 91
Anexo 7
Función Guargar_byte
void Guardar_byte(){ int bits_back, buffer1, buffer2; u32 *dir;
buffer1 = 0; buffer2 = 0; bits_back = 0;
dir = (u32 *)(DIR_BASE_MSG + (canal*280) + cnt_bytes[canal]);
if ((posic_ceros > 0) && (posic_ceros < 16)) { bits_back = ceros[canal]-1; } else if (posic_ceros > 16) { bits_back = ceros[canal]-2; }
else { bits_back = ceros[canal]; }
/* Completando huecos de último byte guardado */ if (bits_back>0) { buffer1 = *(dir-1); buffer2 = octeto >>= (8-bits_back); buffer1 += buffer2; *(dir-1) = buffer1; octeto <<= bits_back; } if (ceros[canal] >= 8){ ceros[canal] -= 8; } else{ *dir = octeto; cnt_bytes[canal]++; }
if (cnt_bytes[canal] > 278){ Rst_canal(canal); // La MSU no puede superar los 278 bytes } return; }
Diseño de un sistema para el monitoreo de la señalización no.7 92
Anexo 8
Funciones para chequeo del CRC
int Chk_error()
{
u32 Gx = 0x88108000; // Gx para SS7 10001000000100001000000000000000 u32 Rx = 0xe8780000; // Rx SS7 rotado 3 a la izq. 11101000011110000000000000000000 u8 temp;
while (cont != cnt_bytes[canal]) { Rellenar(); while (rotac < 16) { rotac += Busca_uno(); if (rotac < 16) trama ^= Gx; } }
if (trama == Rx) { return (1); }
return (0);
}
/****** Garantiza que todo el msg. SS7 se compare con Gx * para completar el chequeo del CRC *****/u32 Rellenar()
{
int n, i; u32 *dir; u32 temp;
dir = (u32 *)(DIR_BASE_MSG + (canal * 280)); temp = 0x00000000;
if (trama == 0x00000000) { n = 4; rotac = 32; } else if (trama & 0x00FFFFFF == 0) n = 3; else if (trama & 0x0000FFFF == 0) n = 2; else n = 0;
if (n > 1) {
Diseño de un sistema para el monitoreo de la señalización no.7 93
for (i = 0; i < n; i++) { if (cont != cnt_bytes[canal]) { temp *= 256; temp += *(dir+cont); cont++; } else n--; }
rotac -= 8*n; temp <<= rotac; trama += temp; }
return (1);
}
/****** Garantiza que el segmento del msg. SS7 a comparar con Gx * siempre comience con ´1´ *****/u8 Busca_uno()
{
u32 temp; int i;
temp = 0x80000000;
for (i = 0; i < (32-rotac); i++) { if (temp & trama != 0) { trama <<= i; return (i); } else temp >>= 1; }
return (32);
}
Diseño de un sistema para el monitoreo de la señalización no.7 94
Anexo 9
Fragmento de código de la función EmacLiteSendFrame
/* Ensambla la trama Ethernet con las MAC de destino y origen */ FramePtr = (u8 *)TxFrame;
/* MAC de destino */ *FramePtr++ = *AddrPtr++; *FramePtr++ = *AddrPtr++; *FramePtr++ = *AddrPtr++; *FramePtr++ = *AddrPtr++; *FramePtr++ = *AddrPtr++; *FramePtr++ = *AddrPtr++;
/* MAC local */ *FramePtr++ = LocalAddress[0]; *FramePtr++ = LocalAddress[1]; *FramePtr++ = LocalAddress[2]; *FramePtr++ = LocalAddress[3]; *FramePtr++ = LocalAddress[4]; *FramePtr++ = LocalAddress[5];
/* Inserta en la trama longitud de la MTU */ *((u16 *)FramePtr) = ++PayloadSize; FramePtr++; FramePtr++;
/* No cuenta los bytes del CRC */ PayloadSize-=3;
/* Llena MTU con msg. SS7 */ for (Index = 0; Index < PayloadSize; Index++) { *FramePtr++ = *(u8 *)dir; dir++; }
PayloadSize+=3; //Restablece cant. de bytes
/* Añade No. aleatorio de msg. a la trama. */ *((u16 *)FramePtr) = msg_number[msg_index++]; if (msg_index > 9) msg_index = 0; FramePtr++; FramePtr++;
/* Añade Id del equipo a la trama */ *FramePtr = ID_SONDA