Universidad de Costa Rica Facultad de Ingeniera Escuela de Ingeniera Elctrica

IE 0502 Proyecto Elctrico

IMPLEMENTACIN DE LA LIBRERA PARA LA SUPERVISIN DE LOS EQUIPOS DE LA RED SDH ALCATEL EN EL SISTEMA DE GESTIN SUPERIOR DE RED DEL INSTITUTO COSTARRICENSE DE ELECTRICIDAD

Por: ARTURO JESS CHAVES VSQUEZ

Ciudad Universitaria Rodrigo Facio Diciembre del 2008

IMPLEMENTACIN DE LA LIBRERA PARA LA SUPERVISIN DE LOS EQUIPOS DE LA RED SDH ALCATEL EN EL SISTEMA DE GESTIN SUPERIOR DE RED DEL INSTITUTO COSTARRICENSE DE ELECTRICIDAD
Por: ARTURO JESS CHAVES VSQUEZ

Sometido a la Escuela de Ingeniera Elctrica de la Facultad de Ingeniera de la Universidad de Costa Rica como requisito parcial para optar por el grado de: BACHILLER EN INGENIERA ELCTRICA Aprobado por el Tribunal:

_________________________________ Ing. Johnny Cascante Ramrez Profesor Gua

_________________________________ Ing. Esteban Jimnez Vargas, Mag. Lector

_________________________________ Lic. Vctor Castillo Castro Lector

DEDICATORIA

A mi madre por su incondicional apoyo y cuyo ejemplo de lucha ante las adversidades ha hecho de m la persona que soy.

ii

RECONOCIMIENTOS

A Dios por haberme dado la fuerza y la voluntad de sobreponerme ante las adversidades y permitirme haber llegado hasta donde estoy.

Al Ing. Esteban Jimnez Vargas por su apoyo y orientacin en la realizacin de este proyecto.

A los dems compaeros del ICE que me transmitieron el conocimiento necesario para realizar este trabajo.

iii

NDICE GENERAL

NDICE DE FIGURAS ................................................................................... vi NDICE DE TABLAS .................................................................................. viii NOMENCLATURA ........................................................................................ ix RESUMEN ....................................................................................................... xi CAPTULO 1: Introduccin ........................................................................... 1
1.1 1.1.1 1.1.2 1.2 2.1 2.1.1 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.4 2.4.1 2.4.2 3.1 3.1.1 3.1.2 3.2 3.2.1 Objetivos .................................................................................................................3 Objetivo general ......................................................................................................3 Objetivos especficos ..............................................................................................3 Metodologa ............................................................................................................4 Redes de telecomunicaciones .................................................................................7 Modelo de referencia OSI .......................................................................................9 Jerarqua digital sncrona ......................................................................................11 Componentes de una Red Sncrona ......................................................................13 Topologas de redes SDH .....................................................................................14 El mdulo de transferencia sncrono ....................................................................15 Esquema de multiplexacin de un STM-N ...........................................................16 Estructuras de multiplexacin de un STM-N .......................................................18 Estructura interna del STM-N...............................................................................20 Gestin de redes de telecomunicaciones ..............................................................30 Generalidades sobre gestin de redes ...................................................................30 Administracin de la red SDH-Alcatel .................................................................34 Supervisin de la red de telecomunicaciones del ICE ..........................................39 Sistema de Gestin Superior del ICE ...................................................................40 Descripcin fsica de la red SDH-Alcatel .............................................................43 Topologa de red ...................................................................................................44 Elementos de red que componen esta tecnologa .................................................46 Comunicacin a travs de la Interfaz IOO1359....................................................56 Establecimiento de la conectividad con la IOO1359 ............................................57 Solicitud y recepcin de alarmas de los equipos de red .......................................61 Protocolo de comunicacin transmitido ...............................................................64 Notificacin de alarmas presentes y espontneas .................................................64 iv

CAPTULO 2: Desarrollo terico .................................................................. 6

CAPTULO 3: Desarrollo de la implementacin ........................................ 56

3.2.2 3.2.3 3.2.4 3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 4.1 4.2 5.1 5.2

Alarmas borradas ..................................................................................................65 Descripcin de los atributos ..................................................................................66 Formato del atributo friendlyName .......................................................................66 Procesamiento de los mensajes recibidos .............................................................73 Estructura general de parseo .................................................................................74 Estructura de asignacin de salidas ......................................................................88 Mapeo del Record Class Out al FaM ..................................................................102 Reglas de subida y Bajada de Alarmas ...............................................................103 Sincronizacin de alarmas ..................................................................................104 Caso 1: Alarma en un equipo ..............................................................................107 Caso 2: Alarma en trayecto .................................................................................111 Conclusiones .......................................................................................................115 Recomendaciones ...............................................................................................115

CAPTULO 4: Comprobacin de la librera AL_SDH_L ....................... 107

CAPTULO 5: Conclusiones y recomendaciones ..................................... 115

BIBLIOGRAFA .......................................................................................... 117 APNDICES ................................................................................................. 119

Apndice 1. Ejemplo de raw data....................................................................................119 Apndice 2. Contenido del atributo probableCause ...........................................................121 Apndice 3. Cdigo Fuente implementado en Gremlin .....................................................126 Apndice 4. Funciones diseadas para Troll ......................................................................132 A4.1 Converter ...............................................................................................................132 A4.2 Filtro_Description .................................................................................................132 A4.3 Filtro_physical_Id_ruta .........................................................................................133 Apndice 5. Tablas para Netrac ..........................................................................................134 A5.1 Tabla Priority_Convert..........................................................................................134 A5.2 Tabla LOOKUP_AL_SDH_DESC (NUEVA) .....................................................134 A5.3 Tabla LOOKUP_AL_SDH_PID (NUEVA) .........................................................135 A5.4 Tabla CONDITION_TYPE ..................................................................................135

NDICE DE FIGURAS

Figura 2.1. Esquema de una red de telecomunicaciones ........................................................ 7 Figura 2.2. Esquema del modelo de referencia OSI ............................................................. 10 Figura 2.3. Equipo SDH ....................................................................................................... 13 Figura 2.4. Topologas de redes SDH ................................................................................... 14 Figura 2.5. Multiplexacin SDH........................................................................................... 16 Figura 2.6. Formacin de una trama STM-N........................................................................ 17 Figura 2.7. Segmentos de redes SDH ................................................................................... 21 Figura 2.8. Estructura de una trama STM-1 ......................................................................... 22 Figura 2.9. Detalle del encabezado en un STM-1................................................................. 23 Figura 2.10. Bytes de encabezado de la seccin de regeneracin ........................................ 24 Figura 2.11. Punteros de Unidad Administrativa ................................................................. 25 Figura 2.12. Encabezado de la seccin multiplexora............................................................ 26 Figura 2.13. Encabezado de Trayecto ................................................................................... 28 Figura 2.14. Arquitectura lgica de una TMN segn la UIT-T ............................................ 32 Figura 2.15. Jerarqua de Sistemas de Gestin ..................................................................... 34 Figura 2.16. Gestin en la tecnologa SDH-Alcatel ............................................................. 35 Figura 2.17. Administracin de fallas en la tecnologa SDH-Alcatel .................................. 37 Figura 2.18. Listado de alarmas en el 1353NM .................................................................... 38 Figura 2.19. Listado de alarmas en el 1354RM .................................................................... 39 Figura 2.20. Flujo de datos en Netrac ................................................................................... 41 Figura 2.21. Ventana Principal del FaM ............................................................................... 43 Figura 2.22. Topologas de la red SDH-Alcatel del ICE ...................................................... 44 Figura 2.23 Topologa 51 a 53 .............................................................................................. 45 Figura 2.24. Anillo 51 ........................................................................................................... 45 Figura 2.25. Detalle de las topologas de red SDH-Alcatel .................................................. 46 Figura 2.26. Vista frontal de un equipo 1660SM ................................................................. 49 vi

Figura 2.27. Diagrama de bloques de un equipo 1660SM.................................................... 50 Figura 2.28. Vista frontal de un equipo 1650SMC ............................................................... 52 Figura 2.29. Diagrama de bloques de un equipo 1650SMC ................................................. 54 Figura 3.1. Ventana de configuracin del subnet ................................................................. 59 Figura 3.2. Ventana de configuracin de detalles del access ............................................... 60 Figura 3.3. Ventana de configuracin de variables del access ............................................. 60 Figura 3.4. Identificacin del tipo de evento para el parseo ................................................. 76 Figura 3.5. Proceso de parseo de la informacin general de una alarma .............................. 78 Figura 3.6. Proceso de parseo de una notificacin alarmClear ............................................ 83 Figura 3.7. Identificacin de alarmas: formato general o default ......................................... 85 Figura 3.8. Identificacin de problemas en ADM o tarjetas internas ................................... 86 Figura 3.9. Identificacin de tipo de componente conectado al equipo ............................... 87 Figura 3.10. Vista principal de la herramienta Troll............................................................. 90 Figura 3.11. Flujo de datos en Netrac ................................................................................... 91 Figura 3.12. Definicin de los campos del FaM a partir de la salida de Troll.................... 103 Figura 3.13. Definicin del proceso de levantado/borrado de alarmas .............................. 104 Figura 3.14. Definicin del proceso de sincronizacin de alarmas .................................... 105 Figura 3.15. Visualizacin de alarmas en el FaM............................................................... 106 Figura 4.1 Muestra de alarma del 1353NM. Caso 1. .......................................................... 108 Figura 4.2. Muestra de alarma del 1354RM. Caso 2. ......................................................... 112

vii

NDICE DE TABLAS
Tabla 2.1 Tamaos de Contenedores .................................................................................... 18 Tabla 2.2 Nmero de bytes por contenedor virtual .............................................................. 19 Tabla 2.3 Descripcin de bloques funcionales de un equipo 1660SM ................................. 51 Tabla 2.4 Descripcin de bloques funcionales de un equipo 1650SMC .............................. 55 Tabla 3.1. Atributos transmitidos en las notificaciones de alarmas...................................... 67 Tabla 3.2. Campos de parseo en notificaciones alarmList o alarmRaise ............................. 80 Tabla 3.3. Campos de parseo del atributo eventTime ........................................................... 81 Tabla 3.4. Campos de parseo en notificaciones del tipo alarmClear ................................... 84 Tabla 3.5. Campos de parseo del atributo friendlyName ...................................................... 89

viii

NOMENCLATURA
ADM Add and Drop Multiplexer. Multiplexor de Insercin- Extraccin. ATM AU Asincronous Transfer Mode. Modo de Transferencia Asncrono. Administrative Unit. Unidad Administrativa.

AUG Admnistrative Unit Group. Grupo de Unidades Administrativas. BML C Business Management Layer. Capa de Gestin del Negocio.. Container. Contenedor. Direccin Tcnica Centro Nacional Gestin y Sistemas del ICE.

DT-CNGS EML EMS FaM GD ICE ISO

Element Management Layer. Capa de Gestin de Elemento de Red. Element Management System. Sistema de Gestin de Elemento de Red. Failure Management. Gestin de Fallas. Generic Driver. Controlador Genrico. Instituto Costarricense de Electricidad. International Standards Organization. Organizacin Internacional de Estndares.

Mbps Megabits por Segundo. MSOH Multiplexer Section Overhead. Encabezado de Seccin del Multiplexor. NE NM Network Element. Elemento de Red. Network Management. Gestin de Red.

NML Network Management Layer. Capa de Gestin de Red. NMS Network Management System. Sistema de Gestin de Red. ONU Organizacin de las Naciones Unidas. OS OSI Operations System. Sistema Operativo Open Systems Interconection. Interconexin de Sistemas Abiertos.

PDH Plesiocronous Digital Hierarchy. Jerarqua Digital Plesicrona. POH Path Overhead. Encabezado de Trayecto. ix

PRC

Primary Reference Clock. Reloj de referencia primario.

RC-IN Record Class IN. Registro de Entrada de la herramienta Troll. RC-OUT RDR REG RM Record Class Out. Registro de Salida de la herramienta Troll.

Raw Data Repository. Repositorio de datos en crudo. Regenerator. Regenerador. Route Management. Gestin de Trayectos.

RSOH Regenerator Section Overhead. Encabezado de Seccin del Regenerador. SDH Synchronous Digital Hierarchy. Jerarqua Digital Sncrona.

SDXC Synchronous Digital Cross Connector. Conexin Digital Cruzada Sincrnica. SML SOH Services Management Layer. Capa de Gestin de Servicios. Section Overhead. Encabezado de Seccin.

SONET Syncronous Optical Network. Red ptica Sncrona. STM-N Synchronous Transfer Module. Mdulo de transferencia sncrono. TM Terminal Multiplexer. Equipo Multiplexor Terminal. Management Network. Red de Gestin de

TMN Telecommunications Telecomunicaciones. TU TUG

Tributary Unit. Unidad Tributaria. Tributary Unit Group. Grupo de Unidades Tributarias.

UIT-T Unin Internacional de las Telecomunicaciones Seccin de estandarizacin. VC Virtual Container. Contenedor Virtual.

RESUMEN
Este proyecto consiste en la adaptacin de los mensajes de alarmas en equipos y trayectos de la red de transporte SDH-Alcatel al sistema de Gestin Superior del Instituto Costarricense de Electricidad. Para efectuar la adaptacin fue necesario realizar un estudio de la infraestructura de dicha red. En esta se identificaron los tipos de equipos y trayectos de red que la componen. Adems se determin que la supervisin de la red era realizada en los Gestores Propietarios Alcatel 1353NM y 1354RM. Tambin se destaca que de estos gestores se puede extraer informacin de las alarmas y enviarla a otros Sistemas de Gestin Superior. En el Sistema de Gestin Superior del ICE se puede lograr la comunicacin con los gestores Alcatel. Adems cuenta con herramientas que toman los datos transmitidos, los divide en bloques de datos, los que al final utiliza para generar eventos de alarmas que se despliegan en un listado. Este ltimo permite la supervisin de la red. Al final de este proyecto se logra implementar la adaptacin diseada con casos de alarmas reales. Estos se comparan con su respectivo evento en los Sistemas de Gestin Alcatel. Adems, este trabajo permiti comprender como funciona el negocio de las telecomunicaciones para garantizar un servicio de calidad a los clientes. Por otra parte se identificaron diversos problemas que no permiten una adecuada supervisin de la red, entre los cuales se pueden citar errores de configuracin de los Gestores Alcatel y limitaciones de conectividad de estos debido a polticas internas del ICE. xi

CAPTULO 1: Introduccin
El Instituto Costarricense de Electricidad (ICE) en su Sector de Telecomunicaciones tiene como visin hacer de esta institucin una empresa propiedad del Estado, competitiva de clase mundial, lder en el mercado de las telecomunicaciones e informacin, con la mejor tecnologa y recurso humano al servicio del cliente y de la sociedad costarricense. Adems ha tomado la misin de satisfacer las necesidades y expectativas evolutivas de los clientes y la sociedad costarricense, mediante el suministro oportuno de servicios y aplicaciones de telecomunicaciones e informacin de calidad, a precios y tarifas competitivos, con la tecnologa adecuada y el mejor recurso humano. Dentro de este esquema, el ICE adquiere toda la infraestructura necesaria para lograr dar un servicio de calidad. Esta consta de un amplio sistema de telecomunicaciones compuesto por redes de diversas tecnologas, las cuales han sido adquiridas a mltiples empresas. Entre estas se pueden citar Alcatel, Samsung, NEC, ECI, entre otras. Para la gestin de las diferentes redes adquiridas, segn sea el fabricante y las condiciones que mediaron en la concesin de su compra, se cuenta con Sistemas de Gestin Propietarios. Cada uno de estos permiten realizar operaciones de monitoreo, control de inventario y configuracin de la red, principalmente. No obstante, para lograr una gestin eficaz de los recursos con que dispone el ICE en su red de telecomunicaciones, es fundamental la adaptacin de esta variedad de equipos y tecnologas a una sola plataforma de supervisin. Como solucin a esto, esta institucin

cuenta con un Sistema de Gestin Superior llamado Netrac, el cual fue adquirido a la empresa TTI-Telecom. Dicha adaptacin se logra enlazando los Sistemas de Gestin Propietarios con Netrac por medio de protocolos de comunicacin, los cuales son establecidos por los fabricantes y entidades internacionales encargadas de la estandarizacin de las telecomunicaciones como la Unin Internacional de las Telecomunicaciones (UIT-T). De acuerdo con esto, en Netrac, una vez establecida la conectividad con un Sistema de Gestin Propietario, se deben definir reglas de programacin, estandarizacin y levantamiento de alarmas para lograr la interpretacin de los mensajes transmitidos y permitir la supervisin de los elementos de red. A lo anterior se le denomina creacin de libreras. En lo que respecta a este proyecto, se identific que la red SDH-Alcatel no estaba siendo monitoreada en Netrac. Inclusive, las nicas maneras en las que operarios del ICE se daban cuenta de que se presentaba algn problema en la red, eran por llamadas de clientes quejndose por afectacin del servicio o porque algn funcionario ocasionalmente ingresaba a los Sistemas de Gestin Propietarios llamados 1353NM y 1354RM. De acuerdo con lo anterior se procedi a realizar un estudio previo sobre caractersticas operativas de la plataforma de la red SDH-Alcatel, la creacin de una librera para lograr la adaptacin de esta a Netrac y la comprobacin de su funcionamiento con alarmas en tiempo real.

1.1

Objetivos

1.1.1 Objetivo general

Lograr la supervisin de los equipos instalados en la Red SDH-Alcatel mediante el desarrollo de un estudio previo y la implementacin del mismo en el Sistema de Gestin Superior del ICE.

1.1.2 Objetivos especficos

Analizar el estado actual, en el campo de supervisin, de los equipos de la red SDHAlcatel a nivel del Centro de Operaciones de la Red del ICE. Investigar y realizar un estudio sobre el funcionamiento de la Red SDH-Alcatel y el Sistema de Gestin Superior del ICE. Analizar las interfaces y protocolos de comunicacin entre los Gestores SDHAlcatel y el Sistema de Gestin Superior del ICE. Realizar una especificacin funcional que defina a partir de los mensajes de

comunicacin, los lineamientos de programacin y estandarizacin de salida a realizarse en el Sistema de Gestin Superior del ICE.

Implementar el estudio previo con las herramientas asociadas a parseo, bases de datos y reglas de subida y bajada de alarmas en el Sistema de Gestin Superior del ICE.

Habilitar la librera diseada y medir su eficiencia en un ambiente de desarrollo con recepcin de datos en tiempo real.

1.2

Metodologa
La siguiente es la metodologa utilizada para la realizacin de este trabajo: Investigacin bibliogrfica sobre el modelo de gestin de redes de telecomunicaciones segn la UIT-T y como es realizada esta en el DT-CNGS del ICE. Investigacin bibliogrfica sobre generalidades de redes SDH as como las recomendaciones estndar de la UIT-T para transmisin de informacin utilizando esta tecnologa. Estudio de cursos impartidos por los fabricantes a funcionarios del ICE sobre la red SDH-Alcatel. Estudio de manuales de los sistemas de gestin de la red Alcatel-SDH enfocado a cmo se realiza la conectividad entre los primeros y el Sistema de Gestin Superior del ICE, as como la interpretacin del protocolo de comunicacin entre ambos en cuanto alarmas en los equipos y trayectos de dicha red.

Estudio de las herramientas asociadas a parseo, bases de datos y reglas de subida y bajada de alarmas utilizadas en el Sistema de Gestin Superior del ICE que permiten lograr la supervisin de los equipos de red.

A partir del estudio anterior, realizar la librera para la supervisin de los equipos en el Sistema de Gestin Superior del ICE y comparar cara a cara las alarmas que se observan en este con las que muestran los Sistemas Alcatel 1354RM y 1353NM.

CAPTULO 2: Desarrollo terico

Se realiza un desarrollo de la teora pertinente a las redes de telecomunicaciones, tomando en cuenta primero aspectos constitutivos de estas, para caer finalmente en cmo se recomienda que sea desarrollada la gestin de estas. Primeramente se describe que es una red de telecomunicaciones ubicndola dentro del modelo de referencia de Interconexin de Sistemas Abiertos (OSI) de la Organizacin Internacional de Estndares (ISO). Adems se da una descripcin de los aspectos ms relevantes de la tecnologa SDH ubicada dentro de este modelo. Tambin se describen las normas de la UIT-T en cuanto a aspectos conceptuales sobre una adecuada gestin de redes de telecomunicaciones. Se pretende con esto introducir temas como la utilizacin de sistemas de gestin de elementos de red, los cuales permiten lograr el monitoreo y la supervisin de los equipos. Por otra parte se describe al Sistema de Gestin Superior del ICE, Netrac, como un componente que permite, entre otras cosas, la supervisin de los equipos de toda la red de telecomunicaciones. Esto se hace ya que, es en este sistema en el que se realiza el desarrollo y la implementacin de la librera, la cual permite verificar la correcta operacin de los equipos de la Red SDH-Alcatel. Por ltimo, para describir qu se puede supervisar al implementar la librera, se realiza una descripcin fsica de la red SDH-Alcatel en cuanto a las topologas y los equipos que la soportan.

2.1

Redes de telecomunicaciones
Una red de telecomunicaciones es un conjunto de elementos tecnolgicos, tanto

del software como del hardware, combinados de tal forma que permiten el intercambio fcil, seguro y rpido de datos e informacin en cualquier formato entre elementos y sistemas de informacin en diferentes localizaciones (Rufn, 2002).

Figura 2.1. Esquema de una red de telecomunicaciones

De acuerdo con esto, una red de telecomunicaciones debe contar con una plataforma tecnolgica que permita lograr el intercambio de datos entre diversos equipos o sistemas de informacin. Abarca desde el medio de transmisin hasta el equipo que se encarga de recibir y enviar datos a travs de estos. En la figura 2.1 se pueden apreciar diferentes elementos y tecnologas que conforman a una red de telecomunicaciones, y cmo se interconectan estos a travs de diferentes rutas o trayectos de red. Se identifican dentro de estos equipos enrutadores, servidores, torres de transmisin, equipos de multiplexacin, etc. Para la UIT-T, un elemento de red, representa el equipo de telecomunicaciones (o grupos/partes del equipo de telecomunicaciones) y soporta el equipo o cualquier tem o grupos de tems considerados que pertenecen al entorno de telecomunicaciones (M.3010, 2002). As, como ejemplos de elementos de red se pueden ubicar los equipos de multiplexacin y las tarjetas que los componen. Dentro del modelo de referencia OSI (ver seccin 2.1.1), las redes de telecomunicaciones se ubican en las capas de red, la de enlace y la fsica. Como menciona Hesselbach, () puede decirse que la capa de red articula el conjunto de enlaces fsicos, mejorados por la capa de enlace de datos, para constituir lo que propiamente se entiende por red de comunicaciones (2002). Esto muestra la estrecha relacin que hay desde el medio fsico (capa fsica), la formacin de paquetes con informacin (capa de enlace) y hasta el enrutamiento (capa de red), a travs de los trayectos que componen una red de telecomunicaciones.

2.1.1 Modelo de referencia OSI

Ante la diversidad y heterogeneidad de sistemas informticos, y la complejidad que supona su interconexin, en 1977 la ISO promovi el desarrollo de un modelo de referencia que permitiera desarrollar una arquitectura de comunicaciones abierta, la cual fuera adoptada por todo sistema informtico en una red de comunicaciones. Es as como en 1983 se publica el estndar ISO 7498 mejor conocido como en el modelo OSI. Este modelo consta de siete capas que permiten abstraer el conjunto de tareas encomendado a una arquitectura de comunicaciones. Estas se muestran en la figura 2.2. En la capa fsica, segn Hesselbach, se definen aspectos como el acoplamiento al medio fsico de transmisin (); la tcnica de modulacin o codificacin empleada; los niveles de tensin, corriente o intensidad luminosa asociados a los distintos smbolos que representan uno o ms bits (2002). La funcin de la capa de enlace consiste en tomar un medio de transmisin en bruto y transformarlo en una lnea que parezca libre de errores de transmisin no detectados a la capa de red. Esto lo logra tomando los datos y subdividindolos en paquetes de bytes que se envan uno tras otro a un receptor, el cual devuelve un mensaje de confirmacin cuando los ha recibido.

10

Figura 2.2. Esquema del modelo de referencia OSI En la capa de red, se controla el funcionamiento de una subred. Se caracteriza por el reenvo de la informacin a travs de los distintos enlaces y sistemas intermedios que constituyen una red de comunicaciones, y el enrutamiento de la informacin, es decir, la eleccin del camino a seguir a travs de la red en funcin de la optimizacin de algn criterio. El concepto de optimizacin toma en cuenta aspectos como el costo, la rapidez, la seguridad, la fiabilidad y el equilibrio de la red, en aras de garantizar un servicio de calidad a los clientes. Otras funciones caractersticas de la capa de red son el control de congestin, tarificacin, interconexin entre redes, entre otras.

11

Por otra parte, segn Tanenbaum, la capa de transporte tiene como una de sus principales funciones aceptar datos de la capa de sesin, dividirlos en unidades ms pequeas si es necesario, pasarlos a la capa de red y asegurar que todos los pedazos lleguen correctamente al otro extremo (1997). Con lo anterior se garantiza la entrega confiable de paquetes por medio de mtodos de correccin de errores. La capa de sesin consiste en un conjunto de herramientas, a disposicin de los programadores, que permiten estructurar y enriquecer el dilogo entre los procesos de aplicacin. Bsicamente, permite y facilita el dilogo entre sesiones en diferentes ordenadores. La capa de presentacin, a diferencia de las capas anteriores en que el proceso de comunicacin involucra la transferencia de bits, se ocupa de la sintaxis y la semntica de la informacin que se transmite. La manera en que se presentan los datos es por medio de cdigos como el ASCII. Adems se logra ubicar en esta los formatos de los archivos. La capa de aplicacin es la capa superior del modelo de referencia OSI. Bsicamente consiste en una interfaz con el usuario.

2.2

Jerarqua digital sncrona

La necesidad de comunicarse y transmitir datos de la manera ms eficiente ha trado

consigo una continua evolucin de las Telecomunicaciones. En este sentido los desarrollos que se han logrado en los medios que componen la capa fsica, han involucrado la

12

introduccin de tecnologas de transmisin que permiten sacarles el mayor provecho posible, mediante la utilizacin de complejas tcnicas de multiplexacin de seales. Ante el desarrollo de mltiples sistemas de transmisin por medios pticos en la dcada de los ochentas, los cuales operaban a diferentes tasas de velocidades, y la necesidad de homologarlos, result necesaria la implementacin de una estandarizacin. As en 1985, la compaa Bellcore, empez a trabajar en un estndar llamado SONET (Syncronous Optical Network, red ptica sincrnica. A esta uni esfuerzos la CCITT (anterior nombre de la UIT-T) por medio de las recomendaciones G.707, G.708 y G.709. A las recomendaciones anteriores se les llama Jerarqua Digital Sncrona (SDH) y definen entre otras cosas velocidades binarias de transmisin, su interfaz de nodo de red y la estructura de multiplexacin de este tipo de arquitectura. En este tipo de red, sus elementos se rigen por una seal de reloj comn, la cual segn la recomendacin G.811 de la UIT-T, es generada mediante un reloj de referencia primario (PRC) de alta precisin. Esto provoca que los NE estn sincronizados entre s. Si por el contrario no se garantizara la sincronizacin, puede producirse una degradacin considerable en las funciones de red e incluso el fallo total de la misma. No obstante, gracias a diversos aspectos que considera esta tecnologa, es posible determinar cundo y dnde se presenta un problema de sincrona.

13

2.2.1 Componentes de una Red Sncrona

Una red SDH se compone de diversos elementos que permiten la conexin entre equipos y configuraciones de topologas. En la figura 2.3 se muestran los equipos ms relevantes. A continuacin se describen estos.

Multiplexores Terminales (TM): Se encargan de combinar seales para generar otras seales sncronas de mayor velocidad.

Multiplexor insercin/extraccin (ADM): por medio de estos es posible insertar y extraer seales PDH y SDH de menor velocidad en un flujo de datos SDH de mayor velocidad.

Figura 2.3. Equipo SDH

14

Cross conectores (SDXC): por medio de estos dispositivos se logra conectar anillos de multiplexores SDH entre s, as como insertar otras seales de una menor velocidad que la transmitida.

Regenerador (REG): Estos se encargan de regenerar el reloj y la amplitud de las seales de los datos entrantes que han sido atenuadas y distorsionadas por la dispersin y otros factores.

2.2.2 Topologas de redes SDH

Una topologa es la disposicin lgica de los elementos (enlaces, nodos) de una red. Gracias a las ventajas que brindan estos equipos SDH es posible realizar diferentes conexiones entre ellos. En la figura 2.4 se muestran los tipos de topologas que se pueden lograr con los equipos SDH.

Figura 2.4. Topologas de redes SDH

15

En una topologa en malla, segn Hesselbach, los distintos nodos estn ms o menos densamente unidos entre s por enlaces directos (en general, de forma arbitraria y sin seguir ninguna jerarqua particular). Cuando cualquier nodo est unido directamente a todos los dems mediante un enlace directo, se dice que la red presenta una topologa de malla completa (2002). Una topologa del tipo anillo consta de nodos que estn unidos en cadena, uno tras otro, cerrndose sta sobre s misma (de manera circular). Por medio de esta es posible lograr dos caminos de enrutamiento para transmitir una seal a un ADM: uno en sentido horario y otro en sentido antihorario a partir de un elemento de red. Por otra parte, en una configuracin en bus, todos los ADM estn unidos por un nico enlace comn. Si se da una falla en una fibra ptica que conecte dos de estos, no habr forma de lograr un enrutamiento alternativo. No obstante, para que una situacin como la descrita no afecte el trfico, normalmente se utilizan dos trayectos ms, uno de recepcin y uno de transmisin. Este mecanismo resulta efectivo si en el equipo multiplexor se tiene una tarjeta de reemplazo, a la cual se conectan los dos trayectos adicionales. Si un puerto de la tarjeta principal falla, inmediatamente la otra tomar los datos que se estn transmitiendo (trfico) para prevenir la afectacin del servicio.

2.2.3 El mdulo de transferencia sncrono

Para lograr comunicar dos o ms equipos SDH es necesario que estos transmitan seales comunes entre ellos. Para esto se debe formar un mdulo STM-N.

16

En su forma bsica un STM-1 es un mdulo de 155.52 Mbps, el cual se forma a partir de la multiplexacin de seales tributarias transmitidas por diversos equipos de red. Como ejemplos de seales se pueden mencionar transmisiones de video, paquetes ATM, etc. En la figura 2.5 se pretende ilustrar la conformacin de un STM-N a partir de diferentes tributarios. En un STM-N, la letra N es un mltiplo entero (1, 4, 16 64) que se multiplica por 155.52 Mbps. As un STM-4 corresponde a una seal que se transmite a 622.08 Mbps.

Figura 2.5. Multiplexacin SDH

2.2.4 Esquema de multiplexacin de un STM-N

Un mdulo STM-N se forma luego de un complejo sistema de multiplexacin, el cual toma las seales tributarias de los equipos de red (carga til) y las concatena agregando bytes de encabezado, que entre otras cosas, brindan informacin que permiten verificar si los datos transmitidos son correctos.

17

En la figura 2.6 se muestra el detalle de cmo se forma un STM-N a travs diversas estructuras de multiplexacin en equipos de la tecnologa SDH. Por otra parte, la descripcin de los bytes de encabezado introducidos en este proceso se realiza en la seccin 2.2.6.

Figura 2.6. Formacin de una trama STM-N Las seales tributarias de 139.264 Mbps, 44.736 Mbps, 2.048 Mbps, etc., que se multiplexan para formar la trama STM-N se observan al costado derecho de la figura. Cada una de las etapas de este proceso se caracteriza por bloques que representan las estructuras

18

de multiplexacin de los datos (C-3, VC-3, etc.), las cuales se comentan en la siguiente seccin.

2.2.5 Estructuras de multiplexacin de un STM-N

A continuacin se explican como intervienen las estructuras de multiplexacin mostradas en la figura 2.6 para la formacin de un mdulo de transferencia sncrono.

2.2.5.1 Contenedor y contenedor virtual (C y CV)

El contenedor corresponde a la primera etapa de multiplexacin. Contienen informacin til, la cual est constituida por seales con diversas tasas de transmisin. Adems en esta etapa se agregan bytes de relleno que permiten adaptar la velocidad de la seal entrante a la del contenedor. Tabla 2.1 Tamaos de Contenedores DENOMINACION C-11 C-12 C-2 C-3 C-4 Seal a Transmitir 1544 Kbps 2048 Kbps 6312 Kbps 44736 Kbps 139364 Kbps

Posterior a la formacin del contenedor, se agrega un encabezado de trayecto. Este contiene informacin relevante que permite garantizar que la seal transmitida sea recibida ntegra. Cuando esto se completa se forma un Contenedor Virtual (VC). Un contenedor virtual puede ser trasmitido completamente en una trama STM-1, o bien en otro VC de mayor tamao.

19

Tabla 2.2 Nmero de bytes por contenedor virtual Tipo de Contenedor VC-11 VC-12 VC-2 VC-3 VC-4 Nmero de bytes 26 35 107 765 2349

As por ejemplo un VC4 es el de mayor orden y puede ser transmitido en una trama STM-1. Pero tambin puede estar compuesto de contenedores virtuales inferiores como VC-3, VC2, VC-11 o VC-12. En la tabla 2.2 se aprecia el nmero de bytes que se transmite en cada contenedor. Como ejemplos de composicin, un VC-4 puede estar formado por un C-4 o tres TUG-3. La formacin de los contenedores virtuales se muestra en la figura 2.6.

2.2.5.2 Unidad tributaria y grupos de unidades tributarias (TU y TUG)

La unidad tributaria (TU) sirve como medio para transmitir un contenedor virtual de bajo orden a uno mayor. El orden de estas viene ligado al del VC que transmiten. As se distinguen las siguientes: TU-11, TU-12, TU-2 y TU-3. Estas unidades tributarias suelen ser agrupadas en Grupos de Unidades Tributarias (TUG). As por ejemplo si se observa la figura 2.6, un TUG-2 se compone de un TU-2, tres TU-12 o cuatro TU-11. Otro ejemplo es que un TUG-3 se compone de un TU-3 o siete TUG-2.

20

2.2.5.3 Unidad administrativa y grupos de unidades administrativas (AU y AUG)

Las unidades administrativas (AU) corresponden a estructuras que adaptan la carga til (datos que se van a transmitir) de un VC de orden superior a una seal STM-N. En este proceso se agregan bytes que funcionan como punteros, los cuales llevan informacin relacionada con la adaptacin realizada (ms detalles en la seccin 2.2.6.2). Al igual que las estructuras de multiplexacin anteriores, las AU pueden ser agrupadas. De esta manera se forma el Grupo de Unidades Administrativas (AUG). Un AUG puede estar conformado por un AU-4 o por tres AU-3. Estos ltimos a la vez son conformados por un VC-4 y un VC-3 respetivamente

2.2.5.4 Mdulo de Transferencia Sncrono (STM-N)

Un mdulo de transferencia sncrono se conforma a partir de los grupos de unidades administrativas y bytes de encabezamiento se seccin (SOH). La estructura interna de estos bytes se describe en la siguiente seccin

2.2.6 Estructura interna del STM-N

Para propsitos de una adecuada administracin y mantenimiento de una red de telecomunicaciones SDH, una trama STM-N se conforma de bytes de encabezamiento de seccin (overhead), los cuales se agregan a las seal tributarias que se reciben en los multiplexores terminales o los de insercin y extraccin.

21

Una seal tributaria que es recibida en un multiplexor terminal recibe bytes de encabezado de la seccin de trayecto (POH) para conformar un contenedor virtual, tal como se coment en la seccin 2.2.5.1. Una vez que este pasa por las estructuras de multiplexacin respectivas, al llegar a la unidad administrativa recibe el encabezado de seccin (SOH), el cual se compone a la vez de los encabezados de las secciones multiplexoras (MSOH) y de regeneracin (RSOH). Esta informacin es muy til ya que permite a los equipos multiplexores (multiplexores terminales y de insercin-extraccin) y regeneradores, identificar problemas en los mdulos transmitidos. En la figura 2.7 se muestra para cada uno de los NE las secciones de encabezado de un STM-N que les corresponden.

Figura 2.7. Segmentos de redes SDH

22

Como se mencion anteriormente, un mdulo STM-1 posee una velocidad de transmisin de 155.52 Mbps. En la figura 2.8 se observa que su trama se conforma de 2430 bytes en serie, que por lo general se ilustra en forma de matriz para hacer ms cmoda su interpretacin, quedando una estructura bidimensional de 9 renglones, con 270 bytes por rengln. La duracin de transmisin de cada trama es de 125 s, la cual supone una frecuencia de repeticin de 8000 Hz. En la figura 2.9 se puede apreciar el detalle de los bytes de encabezado, los cuales se describen con detalle en las secciones 2.2.6.1, 2.2.6.2 y 2.2.6.3.

Figura 2.8. Estructura de una trama STM-1

23

Figura 2.9. Detalle del encabezado en un STM-1

2.2.6.1 Encabezado de seccin de regeneracin (RSOH)

El encabezado de seccin de regeneracin se encarga de transferir informacin entre elementos regeneradores. Este contiene una estructura de 12 bytes, los cuales se indican en la figura 2.10 y se describen a continuacin. Chequeo de paridad (B1): se utiliza para el monitoreo de desempeo de errores. Se calcula para todos los bytes de la trama STM-N anterior despus de codificar. Tramado (A1 y A2): proporciona un patrn de alineacin de trama STM-1.

24

Identificacin del STM-1 (J0): ambos extremos de un enlace establecen sus propios valores exclusivos de transmisin, luego se comparan los valores recibidos con los esperados verificando que concuerden.

Figura 2.10. Bytes de encabezado de la seccin de regeneracin Canales destinados a los usuarios (F1): son asignados para propsitos establecidos por los usuarios. Canales de comunicacin de datos (D1, D2 y D3): siendo de 192 Kbps permiten funciones de administracin, supervisin, alarma y mantenimiento en la red. Canales de comunicacin de voz (E1): utilizados para la comunicacin de voz.

2.2.6.2 Sealadores de unidad administrativa

Con el fin de reducir el retardo de transmisin, un VC se coloca en cualquier parte de la carga til. Dicho de otra manera, la carga til flota dentro de un mdulo STM-N.

25

No obstante, esto no implica problemas al realizar la multiplexacin ya que existen bytes que actan como sealadores en una AU al tomar el VC. Su fin es identificar el primer byte del VC, o sea la posicin donde inicia la carga til transmitida. Estos se indican como H1, H2 y H3 en la figura 2.11.

Figura 2.11. Punteros de Unidad Administrativa Dentro de sus principales funciones se destacan las siguientes: Proporcionan indicaciones y sealizadores referentes al contenido de la trama. Definicin de la posicin de inicio del VC dentro de la trama STM-1. Proporcionan un mtodo para dejar flotar al VC dentro de la trama AU. Proporcionan una indicacin de concatenacin de AU-4.

26

Segn Alvarado, el proceso de concatenacin permite introducir dentro una seal STM-1 de un tamao superior mltiples mdulos STM-1 de menor magnitud (2002), con lo cual se aprovecha los 155.52 Mbps que puede transmitir esta trama.

2.2.6.3 Encabezado de seccin de multiplexora (MSOH)

En la figura 2.12 se indican los bytes correspondientes al encabezado de la seccin de multiplexacin.

Figura 2.12. Encabezado de la seccin multiplexora Esta seccin se encarga de proveer las funciones necesarias para monitorear y transmitir datos dentro de la red de gestin de elementos de red. La informacin que maneja cada uno de los bytes del encabezado de seccin multiplexora se describe a continuacin.

27

Chequeo de paridad (B2): incluye una verificacin de paridad uniforme intercalada por bits de 24 bits de ancho, para monitoreo de comportamiento errneo. La verificacin se calcula para todos los bytes de un mdulo STM-N exceptuando aquellos ubicados en el RSOH. Intercambio de proteccin del multiplexor (K1): estos bytes proporcionan sealamiento entre equipos de terminacin de la seccin multiplexora. Indicacin de defecto remoto (K2): como lo dice su nombre, sirve para devolver una indicacin al extremo de transmisin, de que el extremo recibido ha detectado un defecto de la seccin entrante, o bien, que est recibiendo una seal de indicacin de alarma en un NE remoto. Calidad de sincronizacin (S1): es un indicador que identifica el tipo de fuente de reloj utilizado para cronometrar la seal transmitida. Este byte constituye uno de los cuatro niveles de sincronizacin acordados por el UIT-T, que indican que la fuente utilizada no debe ser usada. Indicacin de error remoto (M1): se utiliza para enviar informacin de comportamiento errneo desde equipo receptor de la seccin de multiplexacin hacia el equipo originario. Canales de comunicacin de datos (D4-D2): constituyen un canal de 576 Kbps para la comunicacin de datos basado en mensajes, incluyendo funciones de administracin, supervisin, alarma y mantenimiento. Canal de comunicacin de voz (E2): este permite la comunicacin de voz en la red.

28

2.2.6.4 Encabezado de seccin de trayecto (POH)

Esta seccin se compone de nueve bytes, los cuales ocupan la primera columna de un STM-1, los mismos estn destinados a manejar toda la informacin concerniente al camino por el cual circular la informacin. En la figura 2.13 se indican estos bytes. Posterior a esta se describe la funcionalidad de cada unos de ellos.

Figura 2.13. Encabezado de Trayecto Trazado del trayecto (J1): Proporciona un mecanismo de mensaje nico para cada trayecto en la red SDH. Verificacin de paridad (B3): Por medio de esta se monitorea algn comportamiento errneo en el nivel VC-4.

29

Etiqueta de la seal (C2): Indica el tipo de cargas tiles que estn asignadas dentro de un contenedor virtual. Puede indicar si un CV no est equipado, o bien describir la asignacin de bits segn la codificacin presente en ella. Estatus del trayecto (G1): Enva informacin de monitoreo de comportamiento desde el equipo terminal receptor hacia el equipo originario. Los bits de 1 a 4 transportan el conteo de errores detectados por B3. El bit 5 indica una Indicacin de Defecto Remoto de trayecto. Canal de usuario (F2 y F3): se asigna para la comunicacin de operadores de red entre terminales del trayecto establecido entre elementos de red. Multitrama (H4): Identifica la trama de la multitrama que est presente en el VC-4 actual. Intercambio automtico de proteccin (K3): se utiliza para proporcionar proteccin a nivel de trayecto por medio de un intercambio en trayectos VC-4 particulares. Monitor de conexin Tandem (N1): soporta el monitoreo del rendimiento de extremo a extremo de una conexin tandem (sub-seccin de trayecto). Sus bits tienen como funcin un conteo que indican errores entrantes y salientes de un STM-1.

30

2.3

Gestin de redes de telecomunicaciones

A nivel internacional existen instituciones que brindan normativas y

recomendaciones que rigen al negocio y la operacin de las telecomunicaciones a nivel mundial. La UIT-T es el organismo designado por la Organizacin de las Naciones Unidas (ONU) para la coordinacin a nivel mundial de las tecnologas de informacin y comunicacin. La funcin de la UIT-T abarca tres sectores fundamentales a saber: radiocomunicaciones, normalizacin y desarrollo. A continuacin se presenta una sntesis de los aspectos ms relevantes sobre gestin de redes de telecomunicaciones de acuerdo a estndares internacionales y cmo se realiza esta en la redes de transmisin SDH-Alcatel y de telecomunicaciones del ICE.

2.3.1 Generalidades sobre gestin de redes

Una red de gestin de telecomunicaciones (TMN de sus siglas en ingls), segn la UIT-T, es una arquitectura para la gestin, que incluye la planificacin, instalacin, mantenimiento, operacin y administracin de redes de telecomunicaciones y servicios (M.3010, 2000). De acuerdo con lo anterior, el objetivo principal de una TMN es proporcionar un marco de gestin de telecomunicaciones, en el cual la introduccin del concepto de

31

modelos genricos de red para gestin permite ejercer una gestin general de equipos diversos, mediante el empleo de modelos de informacin y de interfaces normalizados. La utilidad prctica de la TMN recomendada por la UIT-T es permitir a las empresas dedicadas al negocio de las telecomunicaciones brindar un servicio de calidad, conforme a estndares internacionales, garantizando la satisfaccin del cliente y la operacin de la red. Para esto, la UIT-T propone una arquitectura lgica de niveles que consta de 5 capas funcionales la cual se muestra en la figura 2.14. La Capa de Elementos de Red (NE), est constituida por todos los equipos que soportan el despliegue de servicios de telecomunicaciones a travs de diversas tecnologas de red implementadas, como equipos fsicos y soportes lgicos. Estos comprenden funciones que van desde la conmutacin y transmisin de paquetes de informacin hasta funciones de soporte como localizacin de averas, tarificacin, proteccin, entre otras. La Capa de Gestin del Elementos de Red (EML), segn la UIT-T, comprenden la gestin de cada elemento de red sobre una base individual o de grupo, y soporta una abstraccin de las funciones suministradas por la capa de elemento de red (M.3010, 2000). Dicho de otra manera, administra la configuracin de los elementos de red, las alarmas y su desempeo. La Capa de Gestin de Red (NML) se encarga del soporte a las capas de elementos de red. Tiene como funciones principales la administracin de la conectividad, enrutamiento y proteccin por medio de varias topologas a travs de diferentes regiones.

32

Adems, segn la UIT-T, proporciona la funcionalidad necesaria para gestionar una red, coordinando la actividad a travs de la red, y soporta las demandas de red hechas por la capa de gestin de servicios. Sabe qu recursos estn disponibles en la red, cmo estn interrelacionados y asignados geogrficamente y cmo pueden controlarse los recursos. Tiene una visin global de la red. Adems, esta capa es responsable de la calidad del funcionamiento tcnico de la red real y controlar las capacidades de red disponibles y la capacidad para dar la accesibilidad y la calidad de servicio apropiadas (M.3010, 2000).

Figura 2.14. Arquitectura lgica de una TMN segn la UIT-T La Capa de Gestin de Servicios (SML) tiene que ver con los aspectos contractuales de los servicios que se suministran a los clientes o que estn disponibles para nuevos clientes potenciales, y es responsable de los mismos (M.3010, 2000). Se encarga de tramitar pedidos, quejas y facturacin.

33

La Capa de Gestin del Empresarial (BML) comprende la parte de coordinacin empresarial global: recuperacin de inversin, anlisis de mercado, etc. Para comprender este modelo se describe la siguiente situacin. Cuando un NE falla, este se comunica con un Sistema de Gestin del Elemento de Red (EMS), el cual se ubica en la capa EML, envindole una indicacin de alarma que describe el problema que lo afecta. En este se pueden observar otros eventos que afectan la subred administrada. Luego esta alarma es enviada a un Sistema de Gestin de Red o Superior (NMS), el cual administra toda la red. Es aqu donde se correlaciona el evento generado con otros en otras tecnologas de red. Adems se toman las directrices para aislar la falla y tratar de brindar el servicio a los clientes afectados por medio de otros trayectos de red si fuera posible. La figura 2.15 constituye una forma de visualizar la estratificacin de estas capas a la vez que permite introducir el rea de trabajo del proyecto. La librera que se disea permitir la supervisin, a nivel de alarmas, de los elementos y rutas de la red SDH-Alcatel en el nivel superior (NML) con un NMS. El Sistema de Gestin Superior (NMS) obtiene datos de los Sistemas de Gestin SDH-Alcatel (EMS) y sus equipos ubicados en la capa siguiente. La siguiente parte del proceso descrito sigue en las capas de gestin del servicio y gestin del negocio. Respectivamente en estas se atienden los reclamos presentados por los clientes y se dan otras directrices, que implican la correccin del problema presentado en caso de no ser solucionado en la capa NML.

34

Figura 2.15. Jerarqua de Sistemas de Gestin

2.3.2 Administracin de la red SDH-Alcatel

La gestin de los elementos y rutas de la red de la tecnologa SDH-Alcatel es realizada por medio de los Sistemas de Gestin Propietarios Alcatel 1353NM y Alcatel 1354RM respectivamente. El sistema 1353NM ubicado en la segunda capa de la figura 2.15, recibe las notificaciones de alarmas y de inventario de los elementos de red gestionados; luego el 1354RM tambin como un EMS, administra las rutas por las cuales se transmite la informacin.

35

Figura 2.16. Gestin en la tecnologa SDH-Alcatel En la figura 2.16 se puede apreciar el entorno que abarca la tecnologa SDHAlcatel. Esta red de transporte es gestionada por los Sistemas de Gestin 1353NM y 1354RM en la capa EML. Luego a travs de una interfaz denominada IOO1359, se pueden comunicar los datos a un sistema operativo externo, en cual se ubican los Sistemas de Gestin Superior. Ntese que adems de la informacin mencionada tambin se pueden gestionar otros tipos de redes como las de datos, conmutacin y de acceso de otras tecnologas. La IOO1359 consiste en una interfaz de salida que permite a una aplicacin de gestin externa mantenerse sincronizada con el Gestor de Red Alcatel. Esto es, cada vez que se levante una alarma o bien se cargue en inventario un nuevo equipo, el Sistema de

36

Gestin Externo ser capaz de mantenerse actualizado por medio de notificaciones que recibe a travs de la IOO. De acuerdo con lo anterior, el objetivo de este proyecto, busca permitir la supervisin de dichos elementos de red en el Sistema de Gestin Superior. Esto es posible gracias a la interfaz del Sistema de Gestin Propietario que permite que los primeros tomen la informacin presente en los sistemas 1353NM y 1354RM de la red SDH-Alcatel para su propia supervisin. Tambin en la misma figura 2.16 se identifican las diferencias de los dos Sistemas de Gestin Alcatel. El 1353NM permite el monitoreo de alarmas, rendimiento y mantener un control del inventario y el directorio de los equipos de red. Adems permite la realizacin de operaciones de mantenimiento a distancia de los NE. Por otra parte, el 1354RM monitorea las alarmas que se dan sobre los trayectos de red. Su importancia es tal que por medio de este se puede realizar la creacin de trayectos de red, dando cabida a la realizacin de operaciones de enrutamiento en caso de que se pierda conectividad a travs de alguna ruta. Un ejemplo sobre como se administra una falla en un elemento de la red se muestra en la figura 2.17. Si ocurre una falla en una fibra ptica que une dos ADM, en cada uno de ellos se genera un evento que indica el origen de la falla y su motivo. Este reporte inmediatamente lo recibe el Sistema de Gestin 1353NM y le asigna un nivel de prioridad para mostrarlo dentro de su listado de alarmas (en la figura 2.18 se muestra una vista de un listado de alarmas en el gestor 1353NM).

37

Figura 2.17. Administracin de fallas en la tecnologa SDH-Alcatel

Adems por medio de herramientas de correlacin de alarmas, el Sistema de Gestin 1354RM recibe la notificacin de la falla en el trayecto respectivo. Todas estas se despliegan en un listado como el mostrado en la figura 2.19.

38

Figura 2.18. Listado de alarmas en el 1353NM

39

Figura 2.19. Listado de alarmas en el 1354RM

2.3.3 Supervisin de la red de telecomunicaciones del ICE

El ente se encargado de la atencin de las averas y las emergencias que se presentan en todos los equipos de la red es el Centro de Operaciones de la Red (COR). Para lograr su cometido el COR realiza la supervisin, la correlacin de las alarmas y el

40

diagnstico de las mismas, las cuales son visualizadas en la herramienta de gestin de fallas (FaM) del Sistema de Gestin Superior del ICE. Adems coordina con tcnicos, controla y da seguimiento a los procesos establecidos para la atencin de las fallas. Si el motivo de la avera no puede ser resuelto, se realiza el escalamiento del problema a otros niveles dentro de la organizacin del ICE. Por otra parte, la adaptacin de las diferentes tecnologas que conforman la red de telecomunicaciones al Sistema de Gestin Superior, es realizada por funcionarios de la Direccin Tcnica Centro Nacional de Gestin y Sistemas de ICE (DT-CNGS). Otras funciones que se realizan en este centro son el control inventario y la evaluacin de la calidad de los sistemas y equipos que conforman dicha red.

2.3.4 Sistema de Gestin Superior del ICE

Como se mencion en el primer captulo, Netrac es el nombre del Sistema de Gestin Superior del ICE. Este cuenta con diversas herramientas y procesos que permiten adaptar los elementos de red y los sistemas propietarios para la gestin. Para lograr dicha adaptacin se deben analizar los protocolos de comunicacin propietarios, extraer los datos y hacer que estos sean manejados a travs de las diferentes herramientas con que cuenta Netrac hasta presentarlas en el FaM (ver figura 2.20). La comunicacin de los equipos y gestores de la red de telecomunicaciones se realiza a travs de distintos protocolos. Entre estos se pueden mencionar TL1, SNMP, FTP, Local Fly y Telnet. En el caso de la red SDH-Alcatel, el protocolo de transmisin es propietario y se transmite a travs de la interfaz IOO1359.

41

Figura 2.20. Flujo de datos en Netrac El Octopus es la interfaz visual donde se configura el Generic Driver (GD) y el Access. Constituye la herramienta que permite que Netrac pueda comunicarse con los elementos de red y sus gestores para la recepcin y transmisin de datos, por medio de la creacin de sesiones lgicas (Access). El GD toma los datos transmitidos (raw data) por los NE, los almacena en el Raw Data Repository (RDR) y los enva finalmente al Device Expert (DvXpert).

42

DvXpert es la herramienta encargada de tomar los datos y obtener a partir de estos otras caractersticas que permiten describir de una manera ms amplia lo eventos de alarmas que transmite la red Alcatel. Sus funciones consisten en extraer las partes relevantes del mensaje transmitido (parseo), convertirlo en un evento asignando una nueva estructura de datos manejable en este sistema (traduccin), y el desarrollo de ciertas operaciones sobre estos eventos, tales como almacenarlos en una base de datos histrica y definir una serie de umbrales para indicar cuando estos incidentes pueden convertise en una alarma (validacin). La herramientas responsables de llevar acabo los procesos de parseo, traduccin y validacin se llaman Gremlin, Troll y Threshold respectivamente. Finalmente al establecerse los reglas que permiten que un evento se convierta en alarma, la nueva estructura de datos es asociada al FaM. Esta consiste una aplicacin donde se aislan y se muestran cada una de las alarmas que se reciben de varios elementos de red o sus gestores. Adems, identifica la ocurrencia de una alarma en la red y realiza un anlisis de la causa-raz, con el fin de comprender el origen y entender las consecuencias del evento que se genera. Dentro de las operaciones ms representativas del FaM se pueden destacar el levantamiento, el reconocimiento y la limpieza (eliminar) de alarmas presentes en la red de telecomunicaciones. La alarmas son visualizadas en una interfaz grfica (figura 2.21) que consiste en una tabla en la cual, de acuerdo a la severidad del evento, se atribuye un color que representa su

43

prioridad. Adems cuenta con herramientas que permiten realizar las operaciones descritas en el prrafo anterior.

Figura 2.21. Ventana Principal del FaM

2.4

Descripcin fsica de la red SDH-Alcatel

En este apartado se realiza una breve descripcin de la constitucin fsica de la red

SDH-Alcatel. Primero se introduce cuales son las topologas de red que la constituyen para finalmente describir sus equipos y las principales funciones que realizan.

44

2.4.1 Topologa de red

Fsicamente la red SDH-Alcatel del ICE est compuesta por cinco topologas 51 a 53, 54 y 55, 56 y 57, 58 a 61 y 62. Estas se muestran en la figura 2.22. La numeracin utilizada corresponde a especificaciones del ICE para su red de telecomunicaciones. Cada una de las topologas mostradas se compone de otras en buses y anillos. En la figura 2.23 se muestra el detalle de la topologa 51 a 53. Tal y como se aprecia, esta topologa est compuesta de un anillo (51) y dos buses (52 y 53).

Figura 2.22. Topologas de la red SDH-Alcatel del ICE

45

Figura 2.23 Topologa 51 a 53 Por otra parte, cada configuracin en bus o anillo se componen de elementos de red enlazados de dicha forma. As por ejemplo se puede observar en la figura 2.24 que el anillo 51 se compone de cinco elementos de red ubicados en diferentes localidades, los cuales se comunican entre s a travs de fibra ptica. Se citan dos: Alajuela (ALA) y Fraijanes (FRJ).

Figura 2.24. Anillo 51

46

En general la red SDH-Alcatel del ICE est compuesta de tres anillos, ocho buses y equipos de prueba ubicados en las instalaciones del ICE en San Pedro (Maqueta). En la figura 2.25 se aprecia en detalle la descripcin anterior.

Figura 2.25. Detalle de las topologas de red SDH-Alcatel

2.4.2 Elementos de red que componen esta tecnologa

Esta red se compone de equipos de red Alcatel Optinex de las familias 1660SM y 1650SMC. Estos equipos cumplen con los requerimientos establecidos para elementos de red SDH segn el estndar UIT-T G.707.

47

Estas familias de equipos de red son compatibles con sistemas de tecnologa plesicrona (PDH) y equipos instalados SDH que cumplan con el estndar mencionado. Esos pueden ser configurados para operar como Multiplexores Terminales, como Multiplexores de Insercin-Extraccin o como nodos Cross Conectores para las aplicaciones de enlaces de redes en anillos. Los equipos de la familia 1660SM pueden operar a velocidades de 155Mbps (STM1), 622 Mbps (STM-4) y 2488 Mbps (STM-16), mientras que los de la familia 1650SMC lo hacen a las velocidades de los mdulos STM-1 y STM-4. A diferencia de los equipos de la familia 1660SM, los de la 1650SMC pueden configurarse para operar como regeneradores. Los puertos con que cuentan estos elementos de red pueden trabajar seales tributarias a velocidades de 2, 34, 45 y 140 Mbps, seales elctricas y pticas STM-1. Estos equipos cuentan con relojes internos que se pueden fijar a 2 MHz o 2Mbps. Poseen una funcin denominada controlador del equipo, la cual proporciona configuracin de las unidades y recoleccin de alarmas, estados y datos de monitoreo de desempeo. Esto permite que puedan ser administrados por una computadora personal o bien un Sistema de Administracin de Red como el 1353NM. A continuacin se hace una descripcin fsica de los equipos 1660SM y 1650SMC.

2.4.2.1 Descripcin funcional de los equipos 1660SM

Los equipos de la familia 1660SM estn compuestos primero de una repisa que contiene 21 ranuras para tarjetas en el rea de acceso y 20 ranuras en el rea bsica (figura 2.26). Adems cuenta con repisas para ventiladores.

48

Estos dispositivos pueden operar con tres tipos de tarjetas: Tarjeta de acceso: es una tarjeta que contiene las interfaces fsicas de seal (conectores elctricos). Tarjeta de puertos: es una tarjeta que desempea la elaboracin SDH de la seal. Mdulo Elctrico u ptico: es una tarjeta de acceso especial (de dimensiones pequeas) que se inserta en el panel frontal de algunas tarjetas especficas. En la figura 2.27 se hace una descripcin funcional de las unidades 1660SM por medio de un diagrama de bloques dado por el fabricante. En la tabla 2.3 se resumen las principales funciones de cada uno de los bloques funcionales que se mencionan.

49

Figura 2.26. Vista frontal de un equipo 1660SM

50

Figura 2.27. Diagrama de bloques de un equipo 1660SM

51

Tabla 2.3 Descripcin de bloques funcionales de un equipo 1660SM

BLOQUE Unidad de 140 Elctrica o de 155 Mbps FUNCIONALIDAD Controlador de equipo Cuenta con una interfaz para conectar una Craft Terminal Local (equipo de gestin remoto) Permite la comunicacin con el Sistema de Gestin a travs de interfaces diferentes Proteccin Sincronizacin Controlador de repisa Proporciona la interfaz para el mapeo asncrono de seales PDH de 2 34/45 Mbps a mdulos VC-12 y VC-3 respectivamente. Realiza funciones de interfaz fsica plesicrona, adaptacin a trayecto de bajo orden y terminacin de trayecto de orden inferior. Realiza funciones de interfaz de mapeo de seales de alto orden: interfaz fsica plesicrona, adaptacin a trayecto de bajo orden y terminacin de trayecto de alto orden; para seales de 140 Mbps y VC-4. Realizan funciones de terminal de trayecto: interfaz fsica sncrona, terminacin de seccin de regeneracin, terminacin, proteccin y adaptacin de seccin de multiplexacin, y de adaptacin de seales alto orden: terminacin y adaptacin de trayecto de alto orden; para seales de 155 Mbps Proporciona cuatro interfaces STM-1 bidireccionales, en las que se realizan funciones de terminacin de trayecto y adaptacin a seales de alto orden Proporciona una interfaz ptica STM-4 con funciones de terminacin de trayecto y adaptacin a seales de alto orden Proporciona una interfaz ptica STM 16 con funciones de terminacin de trayecto y adaptacin a seales de alto orden Alimentacin Cable de Orden de Ingeniera (EOW) Entrada / Salida de 2 MHz Alimentacin Interfaz Q3 para la comunicacin con sistemas de gestin Alarma remota y housekeeping Interfaz Q2/RQ2 Proporcionan la interfaz fsica para los diferentes tipos de seales. Permite la proteccin Conmutacin de Proteccin de Equipo para unidades elctricas de 34/45 Mbps y 155 Mbps

EQUICO

MATRIZ

Unidad Elctrica PDH

Unidad SDH de 155 Mbps Unidad STM-4 Unidad STM-16 SERVICIO

CONGI Tarjetas de Acceso Tarjeta de Proteccin

52

2.4.2.2 Descripcin funcional de los equipos 1650SMC

Por otra parte los equipos 1650SMC estn compuestos por diez ranuras para tarjetas, de las cuales tres son para acceso, tres para respaldo, dos de alimentacin, canales auxiliares y de entrada de reloj, y dos para mdulos de acceso (ver figura 2.28).

Figura 2.28. Vista frontal de un equipo 1650SMC Estos cuentan con tarjetas que cumplen funciones como las descritas para los equipos 1660SM: Tarjeta de acceso: es una tarjeta que contiene las interfaces fsicas de seal. Tarjeta de puertos: es una tarjeta que desempea la elaboracin SDH de la seal.

53

Mdulo elctrico u ptico: es una tarjeta de acceso especial (de dimensiones pequeas) que se inserta en el panel frontal de algunas tarjetas especiales.

En la figura 2.29 se hace una descripcin funcional de las unidades 1650SMC por medio de un diagrama de bloques dado por el fabricante. En la tabla 2.4 se resumen las principales funciones de cada uno de los bloques funcionales que se mencionan.

Como el fin de este proyecto no consiste en describir las funciones internas de los equipos de la red SDH-Alcatel, no se dar una descripcin mayor a los NE que la descrita en las tablas 2.3 y 2.4.

54

Figura 2.29. Diagrama de bloques de un equipo 1650SMC

55

Tabla 2.4 Descripcin de bloques funcionales de un equipo 1650SMC

BLOQUE FUNCIONALIDAD Cuenta con dos puertos STM-1 pticos o elctricos que realizan funciones de terminal de transporte (interfaz fsica sncrona, terminacin de seccin de regeneracin, terminacin, proteccin y adaptacin de seccin de multiplexacin) y ensamblador de alto orden (terminacin y adaptacin de trayecto de alto orden). Matriz que desempea funciones de conexin a trayectos de bajo y alto orden y de proteccin. Sincronizacin de funciones. Controlador de equipo. Controlador de repisa. Proporciona la interfaz para el mapeo asncrono de seales PDH de 2 34/45 Mbps a mdulos VC-12 y VC-3 respectivamente. Realiza funciones de interfaz fsica plesicrona, adaptacin a trayecto de bajo orden y terminacin de trayecto de orden inferior. Realiza funciones de interfaz de mapeo de seales de alto orden: interfaz fsica plesicrona, adaptacin a trayecto de bajo orden y terminacin de trayecto de alto orden; para seales de 140 Mbps y VC-4. Realizan funciones de terminal de trayecto: interfaz fsica sncrona, terminacin de seccin de regeneracin, terminacin, proteccin y adaptacin de seccin de multiplexacin, y de adaptacin de seales alto orden: terminacin y adaptacin de trayecto de alto orden; para seales de 155 Mbps Proporciona cuatro interfaces STM-1 bidireccionales, en las que se realizan funciones de terminacin de trayecto y adaptacin a seales de alto orden Proporciona una interfaz ptica STM-4 con funciones de terminacin de trayecto y adaptacin a seales de alto orden Alimentacin Canales Auxiliares Cable de Orden de Ingeniera (EOW) Entrada / Salida de 2 MHz Alimentacin Interfaz Q3 para la comunicacin con sistemas de gestin Alarma remota y housekeeping Interfaz Q2/RQ2 Proporcionan la interfaz fsica para los diferentes tipos de seales. Permite la proteccin Conmutacin de Proteccin de Equipo para unidades elctricas de 34/45 Mbps y 155 Mbps

COMPACT ADM

Unidad Elctrica PDH

Unidad de 140 Elctrica o de 155 Mbps

Unidad SDH de 155 Mbps Unidad STM-4

SERGI

CONGI Tarjetas de Acceso Tarjeta de Proteccin

CAPTULO 3: Desarrollo de la implementacin

En este captulo se realiza el desarrollo de la implementacin de la librera. Para esto se describe primero como se efecta la comunicacin con los gestores Alcatel a travs de la interfaz IOO1359 y como deben ser configurados cada uno de los componentes de Octopus. Posterior a esto se efecta una descripcin de los diferentes tipos de alarmas que se pueden presentar, para definir a partir de estos una regla de parseo en la herramienta Gremlin. Luego se describen cada uno de los registros de salida de la herramienta Troll en cuanto a su significado y cmo se construyen para finalmente representarlos por medio del Threshold en el FaM.

3.1

Comunicacin a travs de la Interfaz IOO1359

Tal como se coment antes, la conexin del Sistema de Gestin Superior con los

gestores propietarios 1353NMy 1354RM, se realiza a travs de la interfaz IOO1359. En esta se transmite el protocolo de comunicacin para la recepcin de datos y las especificaciones respectivas para lograr la supervisin de los elementos de la red SDHAlcatel.

56

57

En este apartado se describe cmo se realiza la conectividad con Netrac y el proceso de comunicacin que se debe establecer entre gestores a travs de la IOO1359 para la solicitud y recepcin de alarmas.

3.1.1 Establecimiento de la conectividad con la IOO1359

De acuerdo a la documentacin de Alcatel, para la realizacin de pruebas y la obtencin de alarmas es necesario establecer una sesin Telnet a travs sockets TCP-IP. Por medio de esta se establece la comunicacin con los puertos de aplicacin de alarmas configurados en la IOO1359. Esta comunicacin se realiza por medio de la direccin IP 100.50.2.2 que corresponde al gestor Alcatel. Los puertos de aplicacin de alarmas son el 5189 y el 5208 para los Sistema de Gestin 1353NM y 1354RM respectivamente. Si el procedimiento se realiza en una consola para pruebas, la sesin telnet se establecera escribiendo una de las siguientes indicaciones: telnet 100.50.2.2 5189 telnet 100.50.2.2 5208

En Netrac esta comunicacin es posible creando un Generic Driver denominado gd_Alcatel_SDH. Luego para este se configuran dos subnets que permiten definir los grupos de elementos de red que utilizan el mismo protocolo y pueden ser conectados por medio del mismo access. Por medio de estos ltimos se establecen los parmetros descritos

58

antes para iniciar la sesin lgica entre el Sistema de Gestin Superior y los Gestores Alcatel. La explicacin del por qu se crean dos subnets es para dar independencia a los procesos de conexin, de manera que si falla esta al recibir las alarmas en los trayectos no se pierda la comunicacin para recibir alarmas de los elementos de red que la componen. Por otra parte se crean dos access ya que las interfaces de alarmas no utilizan el mismo puerto de aplicacin para la comunicacin con los dos gestores Alcatel. En la figura 3.1 se muestra la ventana de configuracin del subnet. Los nombres asignados para cada uno de ellos son sn_Alcatel_SDH_RM y sn_Alcatel_SDH_NM para los gestores 1354RM (denominado Alcatel_1354RM en el inventario de EMS en Netrac) y 1353NM (denominado Alcatel_1353NM). Los parmetros establecidos en los access corresponden primero a detalles como sus nombres ac_Alcatel_SDH_RM y ac_Alcatel_SDH_NM, el tipo de acceso

(notificaciones), y otros ajustes definidos como estndar para este tipo de comunicacin (ver figura 3.2). Posterior a estos se indican las variables (figura 3.3) que permiten la conexin entre los gestores: la direccin IP (100.50.2.2), el puerto de aplicacin (5208 o 5189), protocolo (telnet_notif) y el nombre del script implementado (Alcatel_SDH). El script permite el envo automtico de comandos para el inicio de sesin en los gestores (ver detalle de los comandos en la seccin 3.1.2). En la seccin 3.1.2.2 se da una descripcin del script y cmo funciona este.

59

Figura 3.1. Ventana de configuracin del subnet Se debe aclarar que las ventanas para la configuracin de los subnets y los access son similares en ambas conexiones para aspectos no mencionados en los dos prrafos anteriores. Por otra parte siguiendo el esquema de la figura 2.20, en el Raw Data Repository (RDR) se almacenan los datos de alarmas obtenidos a travs de la interfaz IOO1359. En el apndice 1 se puede observar una muestra de datos almacenos en el RDR.

60

Figura 3.2. Ventana de configuracin de detalles del access

Figura 3.3. Ventana de configuracin de variables del access

61

3.1.2 Solicitud y recepcin de alarmas de los equipos de red

Existen dos maneras de recibir las alarmas presentes en los gestores Alcatel. Estas son: Notificacin de Alarmas Presentes: se recibe un listado de las alarmas que estn almacenadas en los gestores Alcatel. Notificacin Espontnea de Alarmas: Se reciben las alarmas de manera espontnea cada vez que estas ingresan a los gestores Alcatel. Es importante aclarar la diferencia de las notificaciones. En el primer caso slo se reciben las alarmas que actualmente se encuentran presentes en el gestor. No se reciben notificaciones de levantamiento de nuevas alarmas o borrado de alarmas presentes. Cuando se inicia el proceso de comunicacin, se recibe un listado de todas las alarmas presentes en los gestores Alcatel. Luego una vez finalizada la recepcin del listado se comienzan a desplegar alarmas nuevas conforme estas se presentan en los equipos y trayectos de red. Adems se recibe una notificacin de borrado de alarmas cuando ocurra que se halla corregido el problema causante del mensaje de alarma. Es importante destacar que para poder recibir estas notificaciones de alarmas se debe tener en cuenta cmo se establece la comunicacin a travs de la IOO1359. Esta se realiza por medio de comandos, los cuales se utilizan siguiendo los pasos que se describen a continuacin. Se debe aclarar que cada vez que se introduce un comando se debe enviar una secuencia CTRL+D para indicar el final del comando ingresado en caso de que se estn realizando pruebas.

62

3.1.2.1 Pasos para la recepcin de alarmas en tiempo real en una consola

Para efectos de pruebas se pueden utilizar los siguientes pasos para recibir las notificaciones de alarmas presentes en la red SDH-Alcatel.

1.

Se

debe

enviar

el

comando

de

autenticacin

de

usuario

CON_REQ[password] para iniciar la sesin en los gestores. Se debe indicar el password respectivo. 2. Luego se recibe como respuesta el comando CON_CONF[] si la conexin

fue exitosa. En caso contrario se recibir la respuesta CON_REJ[] que indica que la conexin fue rechazada, por lo cual se debe establecer la conexin de nuevo. 3. Posterior a esto, el siguiente paso es ingresar el comando para la solicitud de

alarmas en tiempo real. Este es START_UNSOL_ALARMS_REQ[]. 4. Los gestores envan la confirmacin

START_UNSOL_ALARMS_CONF[], acompaada primero de toda la lista de alarmas presentes o actuales en el Sistema Alcatel. Al trmino de la lista deber aparecer la primitiva DATA_END_NOTIF[]. Luego se comienzan a recibir alarmas cada vez que se presente alguna falla en la red SDH-Alcatel. Un ejemplo de una notificacin de alarmas se muestra en el Apndice 1. Por otra parte, para indicar que la conexin entre los gestores se mantiene, la notificacin HEARTBEAT_REQ[] aparece cada 5 minutos dentro de los datos comunicados. Adems tambin se puede enviar este comando para la verificacin manual, en cuyo caso el sistema de gestin enviar como confirmacin HEARTBEAT_CONF[].

63

3.1.2.2 Envo de comandos en Netrac

En Netrac no es necesario que el usuario ingrese los datos cada vez que se quiere recibir notificaciones de alarmas en tiempo real. Por medio de la creacin de un script se puede establecer el proceso de comunicacin comentado. Este contiene los comandos y otras especificaciones pertinentes al proceso de comunicacin descrito en la seccin 3.1.2.1. El siguiente el cdigo fuente del script implementado. SCRIPT_NAME: Alcatel_SDH SEND: "CON_REQ[password]" WAIT: "*CON_CONF[]*" SEND: "START_UNSOL_ALARMS_REQ[]" SEND: "HEARTBEAT_REQ[]" END_SCRIPT: Este script trabaja de manera automtica. Las instrucciones SEND y WAIT le indican cuando se debe enviar un comando o recibir la notificacin correspondiente respectivamente. As por si ejemplo se tuvo para xito iniciar se espera sesin recibir se la debe enviar

CON_REQ[password], CON_CONF[].

confirmacin

Si ocurriera que no se recibi esto, el script se ejecuta nuevamente para tratar de conectarse a los gestores a travs de la interfaz IOO1359.

64

3.2

Protocolo de comunicacin transmitido

De acuerdo al tipo de evento se pueden recibir tres clases de notificaciones. Como

se coment al, inicio de la seccin 3.1, cuando se solicitan alarmas en tiempo real se recibe primero un listado de alarmas presentes (alarmList). Luego al finalizar este se reciben notificaciones de alarmas espontneas (alarmRaise) y de borrado de alarmas (alarmClear). Para los casos anteriores el contenido de la notificacin de alarmas difiere. En las secciones 3.2.1 y 3.2.2 se detalla la estructura del mensaje transmitido segn sea al caso. Por otra parte en el apartado 3.2.3 se indica el significado de los campos que componen el protocolo recibido.

3.2.1 Notificacin de alarmas presentes y espontneas

En cuanto a las notificaciones de alarmas presentes y espontneas se tiene una estructura similar, cuyo formato es el siguiente:
ALARM_NOTIF[ notificationType = <alarmRaise o alarmList> | currentAlarmId = <valor del atributo> | friendlyName = <valor del atributo> | neLocationName = <valor del atributo> | eventTime = <valor del atributo>| eventType = <valor del atributo>| probableCause = <valor del atributo>| perceivedSeverity = <valor del atributo>| additionalText = <valor del atributo>| specificProblems = {<valor del atributo> |<valor del atributo>|.}| acknowledgementStatus = <valor del atributo> ]

65

Donde alarmRaise en el campo notificationType se refiere a alarmas espontneas y alarmList a alarmas obtenidas de un listado. Se puede notar que luego del texto ALARM_NOTIF[ se despliegan una serie atributos y valores separados entre s por un =. Un ejemplo de atributo es notificationType y uno de valor corresponde a alarmRaise. Adems los atributos se encuentran separados por barras (|) y el final del mensaje de esta notificacin termina al aparecer ]. Es importante aclarar que cuando se recibe un listado de alarmas, esta notificacin se repetir de acuerdo al nmero de eventos registrados en los sistemas de gestin Alcatel, hasta encontrar el comando DATA_END_NOTIF[] que indica el final de la lista. Luego aparecern notificaciones como estas cada vez que se presente un nuevo evento.

3.2.2 Alarmas borradas

Esta notificacin permite identificar cuando una falla es corregida en el elemento de red. Aparece cuando se solicitan alarmas espontneas. El tener el mismo nmero identificador de la alarma (campo currentAlarmId), le permite correlacionar la operacin de borrado con el evento de alarma generado. La estructura de una notificacin de este tipo tiene la siguiente forma:
ALARM_NOTIF[ notificationType=<valor del atributo>| currentAlarmId=<valor del atributo>| friendlyName=<valor del atributo>| eventTime=<valor del atributo> probableCause=<valor del atributo> ]

66

3.2.3 Descripcin de los atributos

En la tabla 3.3 se describen los atributos y los valores posibles transmitidos en las notificaciones de alarmas presentes, espontneas y borradas. Debido a la complejidad de la estructura de los valores que puede tomar el atributo friendlyName, se prefiere describirlo en la seccin 3.2.4. Por otra parte, los valores del atributo probableCause se indican en el Apndice 2.

3.2.4 Formato del atributo friendlyName

Este atributo presenta variantes con respecto a la informacin que puede transmitir. Su contenido, de acuerdo con lo indicado en la tabla 3.1, indica la ubicacin dnde se genera el evento que provoca la alarma. Por ejemplo, esta puede ser un elemento de red como un multiplexor de adicin-extraccin, una tarjeta dentro de l, un puerto en esta ltima, o bien un fallo en el medio de transmisin (como la fibra ptica entre dos NE). Por lo general se indican parmetros que permiten identificar la localidad de elemento de red que presenta alguna falla. Debido a la naturaleza de las herramientas que se utilizan para desarrollar libreras en Netrac, la estructura de la informacin contenida en este atributo se clasifica en dos tipos: cuando la notificacin se presenta en un ADM y cuando ocurre en un trayecto u otro lugar no identificable (por default).

67

Tabla 3.1. Atributos transmitidos en las notificaciones de alarmas

ATRIBUTO DESCRIPCION Indica si la notificacin es una alarma nueva o un listado de alarmas Sirve para identificar de manera nica a cada alarma y es utilizada para correlacionar una alarma con los eventos de limpieza o reconocimiento de una alarma Indica dnde se gener la alarma en una forma textual Indica la localizacin del elemento de red. En una de las pruebas realizadas este campo no tena valores asignados Fecha y hora que ocurri el evento. yyyy: ao, mm: mes, dd: da, hh: hora, mm: minutos, ss: segundos VALORES alarmRaise alarmList

notificationType

currentAlarmId

Tipo: entero

friendlyName

Ver Seccin 3.3.4

neLocationName

Campo vaco

eventTime

yyyymmddhhmmss

eventType

Clasifica cada uno de los eventos de alarmas en: alarma de comunicacin, alarma de calidad de servicio, alarma de error de procesamiento, alarma de equipo y alarma de ambiente

communicationsAlarm qualityofServiceAlarm processingErrorAlarm equipmentAlarm environmentAlarm

probableCause

Describe la posible causa de la alarma por medio de un texto en formato ASCII.

Ver Apndice 2 indeterminate critical major minor warning cleared Texto en formato ASCII Nulo: Llaves vacas {} not ack ack

perceivedSeverity

Indica el grado de severidad de la alarma. Puede ser indeterminada, crtica, mayor, menor, advertencia o borrada.

additionalText

Es el campo de texto adicional por medio del cual los usuarios de los Sistemas Alcatel pueden personalizar la informacin adicional sobre las alarmas. Da una descripcin de los problemas especficos de la alarma por medio de un texto ASCII. Usualmente este campo est vaco. Es el estado de reconocimiento de la alarma. Su valor puede ser no reconocida (not ack) o reconocida (ack).

specificProblems

acknowledgementStatus

additionalInfo

Es la informacin adicional de la alarma (puede contener otros atributos anidados en este atributo, los cuales no se indica en la documentacin cules).

Nulo

68

Esta diferenciacin obedece al hecho de que cuando la alarma es generada en un NE, se recibe informacin concerniente a la ubicacin del ADM, y la tarjeta o puerto afectado en su interior, si es el caso; mientras que si es en un trayecto o un valor desconocido, los datos no siguen una estructura definida.

3.2.4.1 Estructura del atributo friendlyName por default

Como se mencion antes, la estructura de la informacin contenida en el atributo friendlyName para este caso corresponde a las situaciones cuando se recibe la descripcin de un trayecto o un nombre fuera del estndar establecido en la seccin 3.2.4.2. Se recibe en este campo algn valor de la forma: friendlyName=neDefaultLocation| En este caso neDefaultLocation puede tomar valores especficos de acuerdo al gestor del cual se extraen las alarmas. Por ejemplo, cuando se recibe una notificacin del Sistema Alcatel 1353NM se puede recibir una notificacin como estas:
friendlyName=It IS A GENERATED OVERFLOW ALARM| friendlyName=1650_1|

El primer caso corresponde a una alarma que indica que en el gestor 1353NM se rebas la capacidad de almacenar alarmas. El segundo indica que el equipo alarmado es un elemento de red utilizado para pruebas y capacitacin de funcionarios. Estos equipos tienen los siguientes nombres: 1650_1, 1650_2, 1660_1, 1660_2 y 1660_03. Por otra parte si la notificacin proviene del gestor 1354RM, el contenido del atributo friendlyName puede presentar valores como los siguientes:

69

friendlyName=SAP-GDP| friendlyName=MAG PCA/SAN-A_01| friendlyName=GDP-SAP-TRAIL-01| friendlyName=SGSYN BIJ/CUQ-A_01|

En estos casos para efectos de interpretacin, dentro de la informacin contenida se indican las localidades en que se ubican los NE enlazados por algn medio de transmisin (fibra ptica por ejemplo). No obstante, esta puede ser modificada en cualquier momento por un usuario de los gestores SDH-Alcatel. Al ser tan variable el campo friendlyName, cualquier caso diferente del contemplado en la seccin 3.3.4.2 ser ubicado dentro de esta primer clasificacin.

3.2.4.2 Estructura general del atributo friendlyName

El formato general del atributo friendlyName que se espera cuando se presenta una alarma en un equipo es el siguiente: friendlyName=neLocation /admproblemLocation /sdhTPInfo | Ejemplo:
friendlyName=ESC-B12-ADM16-1/r01sr1sl01/port#5-P|

3.2.4.2.1 Campo neLocation El campo neLocation se recibe informacin que permite identificar informacin concerniente a la ubicacin del NE. Esta tiene la forma <location> - <topologyType> - < admName> - < admNumber > /.

70

Un ejemplo es el siguiente ESC-B12-ADM16-1, donde ESC se refiere a Escaz, B12 al bus 12, ADM16 se refiere a un multiplexor de alto orden (puede transmitir hasta STM-16) y 1 se refiere al nmero del ADM en el Bus. En este ejemplo el primer campo (location) corresponde a la localidad en que est ubicado el equipo. Se describe por medio de tres letras. Ejemplo: ESC. El segundo campo indica el tipo de topologa (topologyType), la cual puede ser de anillo o bus (se asignan las letras A y B respectivamente) seguida por un nmero identificador de la misma. Ejemplos: A51, B12. El siguiente campo (admName) es para la descripcin del equipo y viene dado por el nombre del multiplexor, un nmero relativo al orden de la capacidad de transmisin del multiplexor (1, 4 o 16). Ejemplo: ADM16. El ltimo campo indica el nmero del ADM (admNumber) en el anillo o bus en que est operando. Ejemplo: 4.

3.2.4.2.2 Campos admproblemLocation y sdhTPInfo En estos campos se indica informacin que permite conocer el origen de la falla dentro del ADM. Pueden identificarse tres grupos de situaciones: alarmas en puertos, alarmas en tarjetas y alarmas internas del equipo. Alarmas en puertos Estos casos de notificaciones tienen dos estructuras de informacin. La primera corresponde cuando la alarma se genera en la parte fsica del puerto.

71

r <rackNumber> sr <subrackNumber> sl <slotNumber> / (admproblemLocation) <TPName> # <TPNumber> - <physicalPortType> (sdhTPInfo)

Por otra parte si esta se genera en la parte lgica tiene la siguiente forma. Es importante indicar que la parte lgica describe falla durante el proceso multiplexacin. Generalmente se atribuyen a prdidas de seal. r <rackNumber> sr <subrackNumber> sl <slotNumber> / (admproblemLocation) <TPName> # <TPNumber> -# <logicalPortType> (sdhTPInfo)

En la primera lnea de ambas estructuras, r corresponde al rack y viene seguido por su nmero (rackNumber); sr concierne al subrack y sigue su nmero (subrackNumber); y sl es atribuido al nmero (slotNumber) de slot (tarjeta). El campo respectivo al tipo de puerto (physicalPortType) para la red Alcatel, tendr solo tres valores P (PDH), OpS (SDH ptico) y EIS (SDH elctrico). TPName y

TPNumber, indican el tipo de puerto y su nmero respectivamente. Ejemplos:

SPP - A51 ADM4 1 / r01sr1sl01 / port#11- P ALA - A51 ADM4 1 / r01sr1sl01 / port#02-OpS

Por otra parte si la informacin es de la parte lgica se recibir informacin de la jerarqua de multiplexacin SDH alarmada en el campo logicalPorType. Por lo general corresponde a una alarma por prdida de seal. Ejemplos:
QUE-B61-ADM1-1/r01sr1sl09/port#02-#0001-msDC MAN-B54-ADM16-1/r01sr1sl01/port#07-#1-e1MonCTP NIC-B54-ADM16-2/r01sr1sl03/port#04-#01-p12Mon_vc12

72

Alarmas en tarjetas Si el problema que genera la alarma est en una tarjeta conectada al equipo, el campo correspondiente al slot no ser indicado. El problema en la tarjeta se indicar como board#XX, donde XX corresponde al nmero. Con esto el formato para los campos siguientes a neLocation se redefinen como: r <rackNumber> sr <subrackNumber> / board # <boardNumber> (admproblemLocation) (sdhTPInfo)

Ejemplo:
PAQ - B54 - ADM16 1 / r01sr1 / board # 37

Alarmas internas de equipo Si la alarma generada corresponde a problemas internos del ADM o bien casos no identificados (default), el campo posterior a neLocation pude recibir informacin de la forma: friendlyName=neLcoation/admproblemLocation_Default| Los ejemplos ms representativos de este caso son los siguientes.
CLR - B59 - ADM1 - 1/ timingGenerator BIJ - A58- ADM1 - 1 / (protectionGroupId,51) , (protectionUnitId,11010101) SCA B57 ADM16 1 / ExtInP#5 ASE-A62-ADM16-2/T3T6#A-T0SyncPu

73

Estos respectivamente corresponden a situaciones de problemas de temporizacin en el reloj oscilador interno de los ADM, falla en grupos de proteccin, alarmas de housekeeping y falla en relojes externos conectados a los equipos. En los ltimos dos casos la informacin contenida se clasifica en el tipo de punto terminal dentro del ADM (admportName) y su nmero (admportNumber). Si por ejemplo se tiene ExtInP#5 el valor de admportName corresponde a ExtInP y el de admportNumber corresponde a 5. Por lo general un # permite identificar antes de l un tipo de puerto y posterior a este su nmero. Cualquier situacin que no corresponda a la descrita en los casos para alarmas en tarjetas o puertos pueden ser ubicados dentro de esta categora.

3.3

Procesamiento de los mensajes recibidos

En esta seccin se describen cmo el DvXpert trata los datos que toma de la interfaz

IOO1359 a partir del establecimiento de la comunicacin por medio del Generic Driver. En una primera instancia se define la regla de parseo que utiliza Gremlin para seccionar los mensajes de alarmas en bloques. Posterior a esto se define la regla de asignacin de campos de Troll y por ltimo la definicin de los umbrales para generar un evento de alarmas en Netrac.

74

3.3.1 Estructura general de parseo

La regla de parseo se realiza a partir de la descripcin realizada del protocolo de informacin transmitido a travs de la IOO1359. Esta estudia la informacin contenida en cada mensaje de alarma. En una primera instancia se observa si el inicio del mensaje contiene informacin de una nueva alarma, el inicio de la transmisin de una lista de alarmas o bien el cierre su transmisin. Luego toma la alarma y extrae cada uno de los atributos descritos en la seccin 3.2.3. Cuando se identifica que se est extrayendo el atributo friendlyName inicia un proceso ms complejo de parseo, considerando los tipos de alamas identificados en la seccin 3.2.4. Adems, durante la explicacin de la regla, se describen las funciones utilizadas en Gremlin para lograr el parseo de los mensajes de alarmas o sincronizacin transmitidos, segn sea el caso. Tambin se utilizan extractos del cdigo fuente para ilustrar la utilizacin de las primeras. El cdigo fuente completo se muestra en el Apndice 3.

75

3.3.1.1 Identificacin del tipo de evento

El primer campo que se busca identificar se denomina Lf_al_sdh_l_ini. Se realiza por medio de la funcin lookfor de la herramienta Gremlin. Esta busca alguno de los siguientes valores al iniciar el mensaje:
START_UNSOL_DATA_CONF START_LIST_CUR_ALARM_REQ ALARM_NOTIF[ DATA_END_NOTIF[]

Si se encuentra alguno de los dos primeros mensajes, se procede a generar un evento de sincronizacin, el cual se discute en la seccin 3.4.5. Si por el contrario encuentra ALARM_NOTIF[, el siguiente paso ser iniciar la extraccin de datos de la alarma. Por otra parte al obtener el ltimo comando permite que Netrac termine el proceso de sincronizacin y est listo para recibir alarmas en tiempo real (la figura 3.4 ilustra la situacin descrita).

3.3.1.2 Parseo de la informacin general

Al identificar un evento como alarma, se procede a extraer la informacin correspondiente a cada uno de los atributos del protocolo transmitido. Debido a su complejidad, la manera en la que se realiza el parseo del atributo friendlyName se describe en la seccin 3.3.1.3.

76

Figura 3.4. Identificacin del tipo de evento para el parseo Por otra parte, ya que el inicio de los mensajes de levantamiento y borrado de alarmas son similares, primero se procede a buscar por medio de la funcin lookfor el atributo notificationType= y luego un |. Luego por medio de la funcin aligned se extrae el contenido entre ambos (aligned siempre obtiene la informacin entre dos lookfor). La parte del cdigo fuente que realiza esta operacin es la siguiente:
Pack Lf_message_ini : LookFor ("notificationType=", 0, 0, 0, 1) {} //Buscar notificationType Pack Al_Notificationtype : Aligned { Out Export = Copy; } //almacenar valor en Al_Notificationtype Pack Lf_atributEnd_1 : LookFor ("|", 0, 0, 0, 1) { Export = Copy; } // buscar |

El nombre del campo que contiene el tipo de notificacin se llama Al_Notificationtype, este es uno de los bloques de salida (Record Class IN) de Gremlin que

77

posteriormente utiliza la herramienta Troll como entrada. Contiene alguno de los siguientes valores posibles: alarmList, alarmRaise o alarmClear. La indicacin Pack se utiliza siempre que se utilicen funciones que permitan la extraccin de paquetes. Para extraer un paquete se introduce entre las llaves de cada funcin el texto Out Export = Copy. Una vez que se identifica el tipo de notificacin se procede a extraer el resto de la informacin.

Casos alarmList y alarmRaise En ambos casos la estructura de parseo es la misma ya que el protocolo transmitido contiene los mismos campos. El proceso que se utiliza se describe en la figura 3.5. Al igual que con el atributo notificationType, se utilizan las funciones lookfor para encontrar el atributo que se quiere extraer y aligned para extraer los restantes atributos. En la tabla 3.2 se brinda una lista de los campos de parseo, el respectivo bloque de salida y un ejemplo en caso de parsear una notificacin como la siguiente:
ALARM_NOTIF[ notificationType=alarmList| currentAlarmId=138032| friendlyName=FRJ-A51-ADM4-1/r01sr1sl01/port#04-#01-p12Mon_vc12| neLocationName=| eventTime=20070201092052| eventType=communicationsAlarm| probableCause=AIS| perceivedSeverity=major| additionalText=000:| specificProblems={}| acknowledgementStatus=notAck| additionalInfo= ]

78

Figura 3.5. Proceso de parseo de la informacin general de una alarma

79

Es importante anotar que cuando se extrae el atributo friendlyName se utiliza la funcin Lenpack para volver sobre el inicio de su valor y comenzar el procedimiento de parseo que se detalla en la seccin 3.3.1.3. Al buscar el atributo additionalInfo se procede a buscar un ] para identificar el final de la transmisin del mensaje de alarma. Por otra parte cuando se extrae la informacin del atributo eventTime se realiza una operacin similar que la realizada en friendlyName, la cual permite dividir su contenido en bloques que permiten identificar el ao, el mes, el da, la hora, el minuto y los segundos en que se generan la alarma. La manera en la cual se procesan y visualizan los resultados del parseo de este campo se indica en la tabla 3.3.

80

Tabla 3.2. Campos de parseo en notificaciones alarmList o alarmRaise

CAMPO DE PARSEO notificationType currentAlarmId NOMBRE EN EL RECORD CLASS IN Al_notificationType Al_currentAlarmId EJEMPLO alarmList 138032 FRJ-A51-ADM41/r01sr1sl01/port#04-#01p12Mon_vc12 20070201092052

friendlyName neLocationName eventTime

Al_friendlyname Al_neLocationName Al_eventTime

eventType

Al_eventType

communicationsAlarm

probableCause

Al_probableCause

AIS major

perceivedSeverity

Al_perceivedSeverity

additionalText specificProblems acknowledgementStatus

Al_additionalText Al_specificProblems Al_acknowledgementStatus

000: {} notAck

additionalInfo

Al_additionalInfo

81

Tabla 3.3. Campos de parseo del atributo eventTime

CAMPO DE PARSEO

NOMBRE EN EL RECORD CLASS IN

DESCRIPCION

EJEMPLO

ao mes da hora minutos segundos

Lp_yyyy Lp_MoMo Lp_dd Lp_hh Lp_MiMi Lp_ss

Indica el ao del reporte Indica el mes del reporte Indica el da del reporte Indica la hora Indica los minutos indica los segundos

2007 01 11 15 10 36

Para realizar al parseo de estos campos se utiliza la funcin lenpack pero en vez de utilizarla para devolverse se utiliza para leer cierta cantidad de campos hacia delante. As, en el inicio del valor del atributo eventTime se utiliza un lenpack que lee cuatro espacios para extraer el ao, luego otro que se desplaza dos espacios para leer el nmero del mes y as sucesivamente hasta obtener todos los paquetes indicados en la tabla 3.3. Un extracto del cdigo fuente que realiza esta operacin es el siguiente:
Pack Lp_yyyy_1 : LenPack (4, 0) { Out Export = Copy; } //Lee los primeros 4 carcteres Pack Lp_momo_1 : LenPack (2, 0) { Out Export = Copy; } //Lee dos ms: mes Pack Lp_dd_1 : LenPack (2, 0) { Out Export = Copy; } // Lee dos ms: da Pack Lp_hh_1 : LenPack (2, 0) { Out Export = Copy; } // Lee dos ms: hora Pack Lp_mimi_1 : LenPack (2, 0) { Out Export = Copy; } //Lee dos ms: minutos Pack Lp_ss_1 : LenPack (2, 0) { Out Export = Copy; }//Lee dos ms: segundos

82

Caso alarmClear A diferencia de los casos anteriores, un alarmClear en el campo notificationType viene acompaado de una menor cantidad de atributos, razn por la cual la regla de parseo para este caso es menos extensa (ver en la figura 3.6 el diagrama de flujo del parseo). La forma en que se obtienen los bloques de datos es similar, se utiliza la funcin aligned entre dos lookfor para obtener el valor del atributo respectivo. Adems el parseo del atributo eventTime se realiza de la misma manera descrita anteriormente. Por otra parte, para el friendlyName se utiliza el mismo mtodo desarrollado en la seccin 3.3.1.3. Para la definicin de la regla considrese el siguiente ejemplo. En la tabla 3.4 se describen los campos de parseo y los respectivos valores de salida del Gremlin (Record Class IN). Ejemplo:
ALARM_NOTIF[ notificationType=alarmClear| currentAlarmId=380001| friendlyName=CAR-A56-ADM16-4| eventTime=20080521095547| probableCause=Inside Failure ]

83

alarmClear

Busque "|currentAlarmId=

Get yyyy_2 Get probableCause_2

Get currentAlarmId

Get MoMo_2 Busque ]

Busque |friendlyName=

Get dd_2

Get friendlyName

Get hh_2

Busque |eventTime=

Get MiMi_2

Get eventTime_2

Get ss_2

Vuelva al inicio de eventTime_2

Busque |probableCause=

Figura 3.6. Proceso de parseo de una notificacin alarmClear

84

3.3.1.3 Parseo del atributo friendlyName

Una vez que se extrae el atributo friendlyName se procede a devolverse al inicio de su valor para tomar las partes de su contenido que permiten identificar el origen de la alarma. Esto lo realiza el siguiente extracto del cdigo fuente:
Pack Mp_value_fn_ini_1 : Pmath (-2, "-", Al_friEndlyName.Size, 0) { Export = Atoi; } //Se calcula la cantidad de espacios que debe volver el cursor Pack Lp_back_value_fn_ini_1 : LenPack (Mp_value_fn_ini_1.Export, 0) {} //Se hace volver el cursor Pack Lf_Look_char_1 : LookFor ("=", 0, 0, 0, 1) {} //Se busca un =

Tabla 3.4. Campos de parseo en notificaciones del tipo alarmClear

CAMPO DE PARSEO

NOMBRE EN EL RECORD CLASS IN

EJEMPLO

notificationType

Al_notificationType

alarmClear

currentAlarmId

Al_currentAlarmId

380001

friendlyname

Al_friendlyname

CAR-A56-ADM16-4

eventTime

Al_eventTime

20080521095547

probableCause

Al_probableCause

Inside Failure

La funcin Pmath se utiliza para calcular el tamao del atributo friendlyName, para luego devolverlo justo antes del igual en una muestra como
friendlyName=ALA-A51-ADM4-1/timinggenerator|

85

Luego se utiliza la funcin lenpack para desplazarse siete caracteres en el mensaje justo antes del texto ADM. Estos tres caracteres permiten identificar con claridad cuando el mensaje de alarma corresponde a una alarma con el formato general del atributo friendlyName y no al caso default. En el cdigo fuente esta operacin se hace en el paquete Lp_prueba_b. La figura 3.7 permite ilustrar este procedimiento.

Figura 3.7. Identificacin de alarmas: formato general o default Con lo anterior es posible seguir extrayendo la informacin del atributo friendlyName cuando corresponde a casos de alarmas en el equipo, tarjetas o puertos, o bien si corresponde a alarmas en trayectos u otras. Se utiliza la funcin switch para separar ambos casos.

86

Luego la siguiente situacin especial se da cuando se procede a identificar si el mensaje de alarma corresponde solamente al ADM o involucra una parte dentro de este. En ambos casos luego del campo neLocation aparece un | o un / respectivamente. Si aparece este ltimo entonces se sigue parseando el resto de la informacin del atributo friendlyName. Esta eleccin se hace en el switch Sw_get_admprob_location (la figura 3.8 ilustra este procedimiento).

Figura 3.8. Identificacin de problemas en ADM o tarjetas internas

87

Cuando se realiza la extraccin del campo admproblemLocation se verifica la primera letra del mensaje para saber si la informacin es concerniente a una tarjeta o puerto, o bien a alguna parte dentro del ADM (ventilador, reloj, etc.). Al encontrar una r se diferencian estos casos y se procede con el parseo respectivo de los datos de cada uno (figura 3.9).
Get admProblemLocation

Vuelva al inicio de admProblemLocation y lea el primer caracter r Default

Get rackNumber

Vuelva un carcter Lea los prximos 4 y carguelos a admInfo

Figura 3.9. Identificacin de tipo de componente conectado al equipo Debido a que el objetivo de este proyecto no es introducir al lector a utilizar la herramienta de parseo Gremlin, no se contina con el anlisis del resto del cdigo fuente. La explicacin anterior se realiz para permitirle tomar una idea de lo que consiste el proceso de parseo de datos. En caso de existir algn inters de conocer sobre esta herramienta se recomienda estudiar primero el manual de Gremlin y proceder con el anlisis del Apndice 3.

88

En la tabla 3.5 se muestran los campos de parseo del atributo friendlyName, el nombre de cada uno de sus bloques de salida y ejemplos de sus valores para distintos casos de alarmas.

3.3.2 Estructura de asignacin de salidas

El bloque de registro de salida (Record Class OUT o RC Out) se compone del contenido de los campos del registro de entrada (bloques de salida de Gremlin, Record Class IN o RC IN), ya sea con el valor directamente extrado, modificado o compuesto por varios de ellos. Adems, tambin puede incluir informacin adquirida de la base de datos de Netrac la cual se denomina Netcap. Esta funcin de asignacin de salidas se desarrolla por medio de la herramienta Troll. Esta permite crear nuevas estructuras de datos que se pueden utilizar para hacer bsquedas en las bases de datos y construir bloques de salida a partir de la informacin obtenida en estas, por medio de la utilizacin del registro de entrada. En la figura 3.10 se muestra la ventana principal de la herramienta Troll. Al lado superior derecho aparece el registro de entrada (bloques de salida de Gremlin), a la izquierda se observa el registro de salida. La parte inferior derecha es un listado de bloques de funciones que permiten manipular los datos, extraer informacin de bases de datos (lookups) u otras definidas por el usuario.

89

Tabla 3.5. Campos de parseo del atributo friendlyName

CAMPO DE PARSEO neLocation admProblemLocation NOMBRE EN EL RECORD CLASS IN Al_neLocation Al_admProblemLocation DESCRIPCION EJEMPLO

sdhTPInfo

Al_sdhTPInfo

Localizacin de la falla: FRJ-A51ADM, trayecto, etc. ADM4-1 Localizacin de la falla r01sr1sl01 en el ADM. Informacin SDH de la falla: Puerto, tipo, port#04-#01problema de p12Mon_vc12 multiplexacin. Localidad Tipo de topologa Nombre del ADM Nmero del ADM en el anillo o bus Nmero de rack Nmero de subrack Nmero de slot Tipo de punto terminal Nmero terminal del punto FRJ A51 ADM4 1 01 1 01 port 04 OpS

location topologyType admName admNumber rackNumber subrackNumber slotNumber TPName TPNumber physicalPortType logicalportInfo admPortName admPortNumber board boardNumber

Al_location Al_topologyType Al_admName Al_admNumber Al_rackNumber Al_subrackNumber Al_slotNumber Al_TPName Al_TPNumber Al_physicalPortType Al_logicalportInfo Al_admPortName Al_admPortNumber Al_board Al_boardNumber

Tipo de Puerto fisico

Informacin lgica del #01Puerto p12Mon_vc12 Puerto en el ADM Numero del Puerto en el ADM Tarjeta Nmero de la tarjeta ExtInP 5 board 12

Informacin de la tarjeta para indicar tipo de falla ExtI Lp_admInfo admInfo a partir de tabla Lookup_Al_SDL_DESC. Caso default cuando no se identifican los admProblemLocationDefault Lp_extract_admproblemlocation_default casos de admproblemLocation conocidos

90

En la seccin central se realiza la asociacin de bloques de entrada por medio de funciones para conformacin del registro de salida. Las funciones pueden ser programadas para realizar tareas especficas (en el apndice 4 se indican las funciones creadas para la librera implementada). En esta seccin solamente se define como se crean los registros de salida a partir de bloques de entrada y las funciones presentes en la herramienta. No se especifica el detalle de cmo se efecta lo anterior en el desarrollo realizado en Troll.

RC-IN RC-OUT Funcin

Figura 3.10. Vista principal de la herramienta Troll

91

Con el fin de ilustrar los procesos por los que pasan los datos desde que se extraen de los gestores hasta llegar al FaM se muestran en la figura 3.11. En esta se observa que Troll recibe de Gremlin el RC-IN, se comunica con bases de datos (NETCAP) y enva el RC-OUT a Threshold. Finalmente este ltimo genera el evento de alarmas que es llevado al FaM.

Figura 3.11. Flujo de datos en Netrac A continuacin se define cmo se forman cada uno de los elementos del registro de salida a partir de los de entrada o bien a partir de informacin que se encuentra en bases de datos.

PHYSICAL_ID_NS El physical_Id de nivel superior se crea para dos casos. Contiene la informacin que permite ubicar a un ADM. El primero caso de ellos corresponde al caso de una alarma identificada dentro de la estructura general del atributo friendlyName:

92

physical_ID_NS = Al_neLocation El segundo corresponde a la estructura por default. Para esto se utiliza la funcin Filtro_physicalId_ruta, la cual a partir del valor Ne_Index correspondiente a cada subnet permite crear el physical_ID_NS respectivo a alarmas de rutas o de elementos de red (se crearon dos subnets uno para el gestor 1353NM y otro para el gestor 1354RM, sus valores respectivos son 167196 y 167197). Si la informacin corresponde a elementos de red el physical_ID_NS se busca el valor contenido en el registro Al_nedefaultLocation en la columna physical_ID de la tabla LOOKUP_AL_SDH_PID a partir del dato en la columna ne_defaultLocation. Si por el contrario corresponde a una ruta, su valor ser RUTA_ALCATEL. Ejemplo: ALA-A51-ADM4-1

PHYSICAL_ID_NI Similar al caso anterior physical_ID_NI contempla el caso del valor del atributo friendlyName por default. Se utiliza la misma funcin y tabla para asignar su valor a partir del registro Al_nedefaultLocation. Por otra parte cuando la alarma se genera en un ADM o una seccin de este, su valor corresponde nicamente al registro Al_neLocation. No obstante cuando se presenta en una tarjeta o puerto se construye el physical_ID_NI de las siguientes formas respectivas:
physical_ID_NI= Al_neLocation+/+r+Al_rackNumber+sr+AL_subrackNumber+sl+Al_boardNumber physical_ID_NI= Al_neLocation+/+r+Al_rackNumber+sr+Al_subrackNumber+sl+Al_slotNumber

93

Ejemplo: ALA-A51-ADM4-1/r01sr1sl10

A partir de este se puede obtener informacin ms detallada con respecto a tarjetas conectadas a los equipos: ubicacin en el equipo, tipo, etc.

ALR_LOGIC_ID Permite identificar de manera nica una alarma respecto de otras. Si la alarma se produce en un equipo de red se crea de la siguiente forma:
SDH_Alcatel_+Ne_Index+_+Al_neLocation+_AlarmId:+Al_currentAlarmId

Si la alarma corresponde al caso de un trayecto o al caso default se procede a filtrar por medio de la funcin Filtro_physicalId_ruta el valor del physical_ID respectivo al Ne_Index del 1354RM, y a partir de la tabla LOOKUP_AL_SDH_PID el valor respectivo de Al_nedefaultLocation para el Ne_Index del 1353NM. Este se coloca en lugar del campo Al_neLocation. Ejemplos: SDH-ALCATEL_167197_RUTA_ALCATEL_AlarmID:41729 SDH-ALCATEL_167196_ESC-A62-ADM16-5_AlarmID:698941

ALR_ACCESS_ID Corresponde al valor del physical_ID_NS. Permite ubicar el elemento de red o ruta alarmado por medio del physical_ID_NS

94

ALR_ACCESS_TYPE Por especificaciones del ICE este campo contiene solamente la letra C. Esto significa que las alarmas sern bajadas del FaM automticamente en el momento en que se reciba la instruccin para hacerlo.

ALR_ACTION_CODE A partir de la etiqueta SDH_ALCATEL y el contenido de Al_eventType se busca el valor respectivo en la columna DESCRIPTION_ESP, en la tabla CONDITION_TYPE. Su informacin permite identificar el tipo de alarma que se genera (de ambiente, comunicaciones, etc.)

ALR_ADDITIONAL_INFO A partir de la etiqueta SDH_ALCATEL y el contenido de Al_probableCause se busca el valor respectivo en la columna DESCRIPTION_ESP en la tabla

CONDITION_TYPE. Su informacin permite obtener la traduccin de la causa del evento en espaol.

ALR_ADDITIONAL_INFO2 A partir del physical_ID_NI se busca en la tabla CMM_EQP el valor respectivo de la columna EQP_TYPE_ID. Este se utiliza luego para extraer el valor respectivo en la columna EQP_TYPE_NAME de la tabla CMM_EQP_TYPE_REVISION. La informacin obtenida permite conocer la familia del equipo Alcatel afectado.

95

ALR_ADDITIONAL_INFO3 A partir del Ne_Index se busca en la tabla CMM_EQP el valor respectivo en la columna EQP_NAME. Este corresponde al nombre del gestor registrado en dicha tabla.

ALR_ADDITIONAL_INFO4 A partir del physical_ID_NI se extrae su valor en la columna EQP_ID. Luego este se busca en la columna OBJECT_ID de la tabla CMM_OBJECT_ADDRESS y se obtiene el valor correspondiente en la columna CONTACT_ID. Este ltimo se utiliza en la tabla CMM_ADDRESS_BOOK para extraer el valor respectivo en la columna

CONTACT_NAME. Esta informacin indica que la red supervisada en este caso es de transporte.

ALR_ADDITIONAL_TEXT Corresponde al registro Al_probableCause. Contiene la causa probable de evento tal y como se obtiene de la alarma.

ALR_AREA A partir del physical_ID_NI se busca en la tabla CMM_EQP el valor respectivo en la columna SITE_ID. Luego este se utiliza para obtener el valor de REGION_ID en la tabla CMM_SITE. Por ltimo con el REGION_ID y un valor de REGION_TYPE=2 se busca el valor respectivo en la columna REGION_NAME de la tabla CMM_REGION. Esto brinda el tipo de rea en que se ubica el equipo o red.

96

ALR_DESCRIPTION Permite brindar una descripcin ms amplia de la alarma. Se utiliza la funcin Filtro_Description. Esta a partir de Ne_Index indica un valor cuando la falla es en un trayecto o un equipo de red. Si corresponde a un trayecto aparecer informacin con la forma:
ALARMA DE RUTA_ALCATEL en+neDefaultLocation+_Causa+Al_probableCause

Si la alarma se da en el ADM se indica Falla en el equipo (NE). Por otra parte cuando corresponde a una parte de este se utiliza la leyenda Falla en y el valor que se obtiene al extraer el contenido de la columna DESCRIPTION_ESP en la tabla LOOKUP_AL_SDH_DESC a partir del registro Lp_admInfo Si la alarma ocurre en una tarjeta se procede a construir este registro as:
Falla en +Bastidor [ +rackNumber+] Repisa [+subrackNumber+] Tarjeta [+boardNumber+]

Si ms bien el evento se genera en un puerto, entonces el contenido de ALR_DESCRIPTION se construye como:

Falla en +Bastidor [ +rackNumber+] Repisa [+subrackNumber+] Tarjeta

[+boardNumber+]+Puerto [+TPnumber+]

Ejemplos:
Falla en Bastidor [01] Repisa [1] Tarjeta [25] Puerto [01] ALARMA DE RUTA_ALCATEL en IP SCT/CAR_02_Causa: ClientFailure Falla en el equipo (NE) Falla en Puerto Externo del ADM

97

ALR_DEVICE_NAME A partir del physical_ID_NI se busca en la tabla CMM_EQP_DATA el valor respectivo en la columna EQP_NAME. Brinda el physical_ID_NS para el equipo afectado.

ALR_DEVICE_TYPE Indica el tipo de equipo instalado. A partir del physical_ID_NI se busca en la tabla CMM_EQP_DATA el valor respectivo en la columna EQP_TYPE_ID. Este se utiliza para buscar en la tabla CMM_EQP_TYPE_REVISION el valor de la columna

EQP_TYPE_NAME.

ALR_DISTRICT A partir del physical_ID_NI se busca en la tabla CMM_EQP el valor respectivo en la columna SITE_ID. Luego este se utiliza para obtener el valor de REGION_ID en la tabla CMM_SITE. Por ltimo con el REGION_ID y un valor de REGION_TYPE=4 se busca el valor respectivo en la columna REGION_NAME de la tabla CMM_REGION. Con esto se obtiene la localidad en la que se ubica el equipo afectado.

ALR_ELEMENT_STATUS A partir del physical_ID_NI se busca en la tabla CMM_EQP_DATA el valor respectivo en la columna OP_STATUS_CODE. Muestra el estado operativo del equipo segn est asignado a nivel de NETCAP.

98

ALR_EQP_NAME A partir del physical_ID_NS se busca en la tabla CMM_EQP_DATA el valor respectivo en la columna EQP_NAME. Indica el nombre del equipo que presenta el evento de alarma.

ALR_EQP_NUM Nmero de identificacin nico de cada equipo, que se genera automticamente por el sistema al crear el mismo. A partir del physical_ID_NS se busca en la tabla CMM_EQP_DATA el valor respectivo en la columna EQP_ID.

ALR_FROM_SITE Indica el sitio donde se encuentra ubicado fsicamente el equipo. A partir del physical_ID_NI se busca en la tabla CMM_EQP el valor respectivo en la columna SITE_ID. Luego este se utiliza para obtener el valor de REGION_ID en la tabla CMM_SITE. Por ltimo con el REGION_ID se busca el valor respectivo en la columna BUILDING_NAME de la tabla CMM_BUILDING.

ALR_GOLDEN_SITE Es un campo identificador para clientes. Por defecto se debe indicar un punto ..

99

ALR_KEY_WORD Brinda parmetros claves para correlacin y bsqueda de eventos en el histrico. Por defecto se debe indicar un punto ..

ALR_MAINTENANCE_REGION Muestra la regin tcnico-geogrfica a la que pertenece el equipo afectado. A partir del physical_ID_NI se busca en la tabla CMM_EQP el valor respectivo en la columna SITE_ID. Luego este se utiliza para obtener el valor de REGION_ID en la tabla CMM_SITE. Por ltimo con el REGION_ID y un valor de REGION_TYPE=3 se busca el valor respectivo en la columna REGION_NAME de la tabla CMM_REGION.

ALR_MODULE_NAME Su valor corresponde al contenido del bloque Al_friendlyName.

ALR_MODULE_TYPE Indica el tipo de la familia de equipos de red instalados. A partir del physical_ID_NI se busca en la tabla CMM_EQP el valor respectivo de la columna EQP_TYPE. Luego con este se obtiene de la tabla CMM_EQP_TPE_REVISION la columna EQP_TYPE_NAME.

ALR_OBJECT_ID A partir del physical_ID_NI se busca el valore respectivo en la columna EQP_ID en la tabla CMM_EQP. Si se tiene el caso en que hay un puerto alarmado el valor de este

100

registro toma lo que obtuvo de la columna y utiliza tambin Al_TP_Number para buscar en la tabla CMM_PORTS el valor de la columna PORT_ID.

ALR_OBJECT_TYPE Nmero de identificacin del equipo afectado. A partir del physical_ID_NI se busca el valor respectivo en la columna EQP_TYPE_ID en la tabla CMM_EQP

ALR_PRIORITY A partir de la etiqueta AL_SDH_L y el registro Al_perceivedSeverity se busca el valor respecto de la columna PRIORITY en la tabla PRIORITY_CONVERT. Este asigna un nmero de prioridad a partir de la severidad de la alarma.

ALR_PROBABLE_CAUSE Cdigo numrico del fabricante para la posible causa de la alarma. Se le da un valor de 0.

ALR_PROPOSED_ACTION Cdigo numrico para accin correctiva propuesta para el evento segn el fabricante. Se le da como valor un guin -.

ALR_SERVICE_AFECTING Se le da como valor un guin -. Indica el tipo de servicio afectado.

101

ALR_SERVICE_NAME Indicacin de si se encuentra el servicio afectado. Se le da como valor un guin -.

ALR_SPECIFIC_PROBLEM Cdigo numrico del fabricante que especfica del problema que genera el evento. Se le da un valor de 0.

ALR_TIME_UP Se crea la fecha y hora en que se gener la alarma de la siguiente manera:

Lp_dd+/+Lp_MoMo+/+Lp_YYYY+ +Lp_hh+:+Lp_MiMi+:+Lp_ss

As un ejemplo de fecha es 27/10/2008 15:45:32.

ALR_TO_SITE Sitio ms prximo de conexin del equipo. Se le da como valor un punto ..

ALR_TYPE Tipo del evento que est afectando al equipo. Se le da como valor el contenido del registro de entrada Al_eventType.

102

SYNC_STATUS Es importante anotar que cuando se tiene el inicio o final de un mensaje de sincronizacin se utiliza un valor de + o -, respectivamente, en el registro de salida SYNC_STATUS. Se verifica en el registro de entrada Lf_al_sdh_l_ini si el valor corresponde a LIST_CUR_ALARMS_CONF[] o START_UNSOL_ALARMS_CONF[] para iniciar la sincronizacin o bien si es DATA_END_NOTIF[ si corresponde el cierre.

3.3.3 Mapeo del Record Class Out al FaM

Para realizar la sincronizacin de alarmas se utiliza la herramienta Threshold. En esta se asocian cada uno de los campos del registro de salida de Troll con las columnas del FaM. En la figura 3.12 se muestra como se realiza el procedimiento anterior. Por ejemplo para configurar el valor de Access ID se arrastra el valor de registro de salida ALR_ACCESS_ID al espacio en la columna Value. Este procedimiento se debe repetir para asignar los restantes campos del FaM.

103

Figura 3.12. Definicin de los campos del FaM a partir de la salida de Troll

3.3.4 Reglas de subida y Bajada de Alarmas

Para definir la regla de subida y bajada de alarmas se utiliza el registro de salida de Troll ALR_PRIORITY. Cuando la alarma corresponde al tipo alarmClear el valor que se asigna este campo es 0. Si por el contrario se recibe una alarma su valor estar condicionado a la severidad del evento (siempre ser mayor o igual a 1). En la figura 3.13 se muestra la configuracin de este proceso en Threshold. Cuando se produce una nueva alarma si la severidad de esta es superior al valor 1 se levanta la alarma y se visualiza en el FaM.

104

Por otra parte cuando se produce un mensaje de alarmClear, a partir del logic_Id se identifica la alarma presente en el FaM y se procede a borrar esta.

Figura 3.13. Definicin del proceso de levantado/borrado de alarmas

3.3.5 Sincronizacin de alarmas

Para realizar el proceso de sincrona de alarmas se utiliza el valor asignado en el registro de salida de Troll SYNC_STATUS. Cuando este tiene un valor de + quiere decir que se iniciar el envo de un listado de alarmas. Por el contrario recibir un - indica que el listado para la sincronizacin ya termin. Esto se configura en la ventana de definicin del Threshold mostrada en la figura 3.14. Durante el proceso de sincronizacin de alarmas, Netrac recibe todas las alarmas presentes en la red SDH-Alcatel. Si existen alarmas que no han sido desplegadas en el FaM

105

estas son tratadas como nuevas. Si por el contrario, se reciben alarmas que ya estaban, el campo llamado Repeated Count se incrementa en uno, indicando que se recibi una alarma repetida.

Figura 3.14. Definicin del proceso de sincronizacin de alarmas Si se observa nuevamente la figura 2.20, se puede notar que Threshold constituye el final del proceso del DvXpert. Ahora los datos estn listos para ser visualizados en el FaM (en la figura 3.15 se muestra un listado de alarmas en l).

106

Figura 3.15. Visualizacin de alarmas en el FaM

CAPTULO 4: Comprobacin de la librera AL_SDH_L

En la seccin 3.4 se describieron las pautas para la creacin de la librera para la supervisin de los equipos y trayectos de la red SDH-Alcatel. A esta se le llam AL_SDH_L, y los procesos que la conforman son los indicados en la figura 2.20. En este captulo se procede a comprobar el funcionamiento de la librera. Para efectos de comprobacin se toman dos casos de alamas obtenidas de las pruebas realizadas el da 31 de octubre, los cuales se identificarn como casos de prueba en las secciones de este captulo. Se evala el contenido del raw data, la notificacin presente en el gestor Alcatel respectivo y cmo se visualiza esta en el FaM.

4.1 Caso 1: Alarma en un equipo

Se utiliza la siguiente muestra de alarma ubicada en la localidad Juan Vias:

ALARM_NOTIF[ notificationType=alarmList| currentAlarmId=698849| friendlyName=JUV-A56-ADM16-1/ExtInPt#1| neLocationName=| eventTime=20080404121819| eventType=environmentalAlarm| probableCause=Housekeeping Alarm| perceivedSeverity=warning| additionalText=CPI1| specificProblems={}| acknowledgementStatus=notAck| additionalInfo=]

107

108

En la muestra del raw data se observa que el identificador de la alarma es el nmero 698849, el cual ser indicado en el logical_Id. Adems el valor de Ne_Index correspondiente a una alarma del gestor 1353NM es 167196. A la severidad warning de acuerdo con la tabla PRIORITY_CONVERT se le asigna una prioridad 3. Adems este evento constituye una alarma de ambiente (environmentalAlarm) y su causa es Housekeeping. Esta alarma se observa en el listado de alarmas de 1353NM como en la figura 4.1.

Figura 4.1 Muestra de alarma del 1353NM. Caso 1. En el FaM del Sistema de gestin Superior puede exportar el listado de alarmas. Los siguientes son los valores de esta alarma en cada una de sus columnas.
Deffered: Work Log: Permission:! Logic Id:SDH-ALCATEL_167196_JUV-A56-ADM16-1_AlarmID:698849 _ P/C: Module Name:JUV-A56-ADM16-1/ExtInPt#1 Action Code:Alarma de Ambiente Additional Text:Housekeeping Alarm Priority:3 Description:Falla en Puerto Externo del ADM From Site:Juan Vias Edif. Time Up:23/10/2008 08:47 To Site:. Eqp Name:JUV-A56-ADM16-1 Importance:0 TT Id: TT Status: Acks: Ack User Name: TT Last Update: TT System:

109

Access Id:JUV-A56-ADM16-1 Access Type:C Additional Info:Alarma de Housekeeping Area:Perifrica Device Name:JUV-A56-ADM16-1 Device Type:Alcatel 1660sm District:Juan Vias-Jimenez Eqp Num:1187 Inhibit:n Keyword:. Module Type:Alcatel 1660sm Object Id:1187 Object Type:2800 Probable Cause:0 Proposed Action:0 Specific Problem:0 Topology:. Trend Indication:1 Type:environmentalAlarm Defer Time: Defer Timeout: Repeated Time:30/10/2008 00:57 Repeated Count:2 Corrective Action: Element Status:37 Maintenance Region:Cartago Planned Work:. Cleared: Golden Site:n UnAcknowledged Escalation Original Priority: Uncleared Escalation Original Priority: Worklog Count: Work Order: Service Name: Service Affecting:0 Additional Info 2:Alcatel 1660sm Additional Info 3:Alcatel_1353NM Additional Info 4:Transporte Ownership Time:

Al analizar algunas de las columnas se puede apreciar lo siguiente. El campo Logic_ID contiene el Ne_Index indicado para alarmas del gestor 1353NM (167196), la ubicacin del equipo multiplexor (JUV-A56-ADM16-1)

110

y el mismo nmero indicador de alarma que la muestra de raw data (698849). La columna Type contiene el valor del campo eventType, el cual corresponde a la columna Alarm Type del listado del 1353NM. La columna additionalText contiene el valor del campo probableCause y coincide con la respectiva columna del listado de 1353NM. La columna description contiene la descripcin que se obtiene de la tabla Lookup_AL_SDH_DESC al buscar en ella el valor ExtI contenido en friendlyName. Esta corresponde a una alarma en un puerto externo conectado al equipo. La columna ModuleName, coincide con el atributo friendlyName del raw data y del listado del 1353NM. En el campo Additional Info 3 se puede apreciar el nombre del gestor del cual se obtuvo la alarma (Alcatel_1353NM). De acuerdo con las especificaciones este se obtiene del valor del Ne_Index 167196. La prioridad 3 coincide con el valor correspondiente en la tabla PRIORITY_CONVERT para una alarma de severidad warning. Por otra parte se puede apreciar que algunas de las columnas no presentan valores asignados. Esto se debe a que son campos exclusivos para los operadores del FaM (funcionarios del ICE y de TTI-Telecom).

111

En otros campos como Maintenance Region, District, Device Type y Additional Info 2 la informacin obtenida no est implcita en el raw data. No obstante estas se obtienen de las tablas de Netrac en Netcap relativas al inventario a partir del physical_Id (creado a partir del raw data). Por esa razn es que se puede observar la localidad y el distrito en qu est ubicado el equipo y la familia Alcatel del elemento de red afectado (1660sm). Si se observa la fecha y hoya del evento en el raw data y en el FaM se puede notar que difieren. La razn de esto es que en el ltimo se indica la fecha y hora en la que se registr el evento en Netrac y no en el elemento de red.

4.2 Caso 2: Alarma en trayecto

A continuacin se analiza el caso de una alarma en una ruta de la red SDH-Alcatel. Como en el caso anterior, se analizan los campos respectivos en el raw data, en el listado de alarmas del 1354RM y en el FaM. La siguiente es la muestra de raw data respectiva.
ALARM_NOTIF[ notificationType=alarmList| currentAlarmId=81556| friendlyName=JIC-PNA| neLocationName=| eventTime=20080711081908| eventType=communicationsAlarm| probableCause=MediaFailure| perceivedSeverity=major| additionalText=|specificProblems={}| acknowledgementStatus=ack| additionalInfo={1.3.6.1.4.1.12.2.2.19=physicallink|1.3.6.1.4.1.12.2.2.20=inService}]

112

En el gestor 1354RM la alarma de muestra de la siguiente manera:

Figura 4.2. Muestra de alarma del 1354RM. Caso 2. Del FaM se extrae la siguiente informacin para este evento.
Deffered: Work Log: Permission:! Logic Id:SDH-ALCATEL_167197_RUTA_ALCATEL_AlarmID:81556 _ P/C: Module Name:JIC-PNA Action Code:Alarma de Comunicacin Additional Text:MediaFailure Priority:5 Description:ALARMA DE RUTA_ALCATEL en JIC-PNA_Causa: MediaFailure From Site:Site_Global Time Up:23/10/2008 08:47 To Site:. Eqp Name:ALCATEL_SDH Importance:0 TT Id: TT Status: Acks: Ack User Name: TT Last Update: TT System: Access Id:RUTA_ALCATEL Access Type:C Additional Info:Falla del medio Area:GLOBAL Device Name:ALCATEL_SDH Device Type:ALCATEL_SDH_GENERICO District:Localidad_Global Eqp Num:172637 Inhibit:n Keyword:. Module Type:ALCATEL_SDH_GENERICO Object Id:172637 Object Type:3170 Probable Cause:0 Proposed Action:0

113

Specific Problem:0 Topology:. Trend Indication:1 Type:communicationsAlarm Defer Time: Defer Timeout: Repeated Time: Repeated Count:1 Corrective Action: Element Status:37 Maintenance Region:Zona_Global Planned Work:. Cleared: Golden Site:n UnAcknowledged Escalation Original Priority: Uncleared Escalation Original Priority: Worklog Count: Work Order: Service Name: Service Affecting:0 Additional Info 2:ALCATEL_SDH_GENERICO Additional Info 3:Alcatel_1354RM Additional Info 4:Transporte Ownership Time:

A continuacin se analizan algunos de los resultados de la columna del FaM con los datos del raw data y la tabla de alarmas de gestor 1354RM. El Logic_ID contiene el Ne_Index (167197) correspondiente al Gestor Alcatel_1354RM, la leyenda RUTA_ALCATEL que indica que la alarma corresponde al gestor de rutas y el mismo nmero indicador de alarma (81556) que el raw data (currentAlarmId) La columna Action Code concuerda con la traduccin del atributo eventType del raw data (columna Alarm Type del gestor 1354RM). El campo Additional Text contiene el valor del atributo probableCause (Columna Probable Cause en el Gestor)

114

El valor de la columna Type es similar al contenido del atributo alarmType. El contenido del campo access Id corresponde al valor del physical Id del gestor (RUTA_ALCATEL), el cual se obtiene de la tabla CMM_EQP al buscar el valor del Ne_Index.

El campo Additional Text contiene el nombre del gestor 1354RM obtenido a partir del Ne_Index.

Lo anterior consiste en algunas de las concordancias de las alarmas en cada uno de los gestores y la informacin obtenida por medio del raw data. Otros campos que hacen referencia a las bases de datos contienen los valores asignados para un elemento de red genrico que se cre ya que las rutas no forman parte del inventario. Este permite indicar valores como RUTA_ALCATEL para el physical Id, Zona Global para la columna Maintenance Region, ALCATEL_SDH_GENERICO para los campos Device Type y Module Type, entre otros. As es posible permitir asociar la alarma con un evento generado en una ruta de la red de transporte SDH-Alcatel.

CAPTULO 5: Conclusiones y recomendaciones

5.1

Conclusiones
Una empresa de telecomunicaciones debe definir sus procesos tomando en cuenta los estndares y recomendaciones internacionales. Se identific que los elementos y trayectos de la red SDH Alcatel no son supervisados en Netrac. Se logr comprender como opera la red SDH-Alcatel y los procesos para identificar las alarmas en sus gestores. Se pudo comprender como funciona Netrac y los procesos para implementar en este, las alarmas generadas en otras redes. La implementacin de la librera fue exitosa en cada una de las herramientas de Netrac utilizadas. Al habilitar la librera en un ambiente con recepcin de alarmas en tiempo real se logr obtener las mismas alarmas tanto en Netrac como en los gestores Alcatel.

5.2

Recomendaciones
Al adquirir una plataforma de red debe especificarse que esta est debidamente documentada.

115

116

Se deben actualizar la informacin de las tablas creadas en Netrac con respecto a valores no establecidos del atributo probableCause.

Se recomienda brindar una gua de las mejores prcticas para lograr el cdigo fuente utilizado en Gremlin pueda ser comprendido por los funcionarios que realicen futuros desarrollos.

Se debe evaluar la eficiencia de las herramientas de Netrac en versiones nuevas de Windows para evitar problemas con las herramientas utilizadas en DvXpert.

Puede resultar til tener un inventario de los errores que genera la herramienta Troll y cmo mitigarlos, aprovechando que se genera un nmero por cada error encontrado.

Puede considerarse verificar la conectividad con los gestores de datos, verificando que la notificacin HEARTBEAT_REQ[] se presenta cada cinco minutos.

BIBLIOGRAFA
Libros: 1. Alvarado S., Eduardo. Diseo y Formulacin del Manual de Operaciones y Mantenimiento para el Equipo SDH SMS-2500 de la Marca NEC, ITCR, Costa Rica, 2002. 2. Hesselbach S., Xavier. Anlisis de Redes y Sistemas de Comunicaciones, I Edicin, Ediciones UPC, Espaa, 2002. 3. Rufn Moreno, Ramn, Las Empresas Tursticas en la Sociedad de Informacin, I Edicin, Editorial Universitaria Ramn Areces, Espaa, 2002. 4. Tanenbaum S., Andrew. Computer Networks, IV Edicin, Prentice Hall, Canad, 2003. 5. Tanenbaum S., Andrew. Redes de Computadoras, III Edicin, Prentice Hall, Mxico, 1997.

Artculos de revistas: 6. Recomendacin UIT.T G.707, Interfaz de Nodo de Red para la Jerarqua Digital Sncrona, 2000. 7. Recomendacin UIT.T G.708, Interfaz de Nodo de Red sub STM-0 para la Jerarqua Digital Sncrona, 1999. 8. Recomendacin UIT.T G.709, Interfaces para la Red de Transporte ptica, 2003. 117

118

9. Recomendacin UIT.T G.811, Caractersticas de Temporizacin de los Relojes de Referencia Primarios, 1997. 10. Recomendacin UIT-T M.3010, Principios para una Red de Gestin de las Telecomunicaciones, 2000.

Pginas web consultadas: 11. Sandoval, J., SDH, www.cec.uchile.cl/~jsandova/el64e/clases/sdh.pdf. 12. Sandoval, J., Socket, www.cec.uchile.cl/~jsandova/el64e/clases/ejsocket.pdf.

APNDICES
Apndice 1. Ejemplo de raw data
A continuacin se muestra un ejemplo de los mensajes que se pueden obtener por medio de una prueba a travs de la interfaz IOO1359 o bien, los datos que se almacenan en los RDR.
ALARM_NOTIF[notificationType=alarmPurge|purgeAlarmsList={99783}]ALARM_NOTIF[notificationTyp e=alarmRaise|currentAlarmId=100546|friendlyName=SBIU3/SVID1_02|neLocationName=|eventTime=2008 1024101252|eventType=communicationsAlarm|probableCause=ClientFailure|perceivedSeverity=warning|add itionalText=|specificProblems={}|acknowledgementStatus=ack|additionalInfo={1.3.6.1.4.1.12.2.2.20=notInS ervice|1.3.6.1.4.1.12.2.2.19=path}]ALARM_NOTIF[notificationType=alarmClear|currentAlarmId=100546|fri endlyName=SBIU3/SVID1_02|eventTime=20081024101303|probableCause=ClientFailure]ALARM_NOTIF [notificationType=alarmPurge|purgeAlarmsList={100546}]ALARM_NOTIF[notificationType=alarmRaise|c urrentAlarmId=100547|friendlyName=SBIU3/SVID1_02|neLocationName=|eventTime=20081024101302|ev entType=communicationsAlarm|probableCause=ClientFailure|perceivedSeverity=warning|additionalText=|sp ecificProblems={}|acknowledgementStatus=ack|additionalInfo={1.3.6.1.4.1.12.2.2.20=notInService|1.3.6.1.4. 1.12.2.2.19=path}]ALARM_NOTIF[notificationType=alarmClear|currentAlarmId=100547|friendlyName=SB IU3/SVID1_02|eventTime=20081024101312|probableCause=ClientFailure]ALARM_NOTIF[notificationTyp e=alarmPurge|purgeAlarmsList={100547}]ALARM_NOTIF[notificationType=alarmRaise|currentAlarmId=1 00548|friendlyName=SBIU3/SVID1_02|neLocationName=|eventTime=20081024101342|eventType=commu nicationsAlarm|probableCause=ClientFailure|perceivedSeverity=warning|additionalText=|specificProblems={ }|acknowledgementStatus=ack|additionalInfo={1.3.6.1.4.1.12.2.2.20=notInService|1.3.6.1.4.1.12.2.2.19=path }]ALARM_NOTIF[notificationType=alarmClear|currentAlarmId=100548|friendlyName=SBIU3/SVID1_02| eventTime=20081024101356|probableCause=ClientFailure]ALARM_NOTIF[notificationType=alarmPurge|p urgeAlarmsList={100548}]ALARM_NOTIF[notificationType=alarmRaise|currentAlarmId=100549|friendly Name=SBIU3/SVID1_02|neLocationName=|eventTime=20081024101354|eventType=communicationsAlarm |probableCause=ClientFailure|perceivedSeverity=warning|additionalText=|specificProblems={}|acknowledge mentStatus=ack|additionalInfo={1.3.6.1.4.1.12.2.2.20=notInService|1.3.6.1.4.1.12.2.2.19=path}]ALARM_N OTIF[notificationType=alarmClear|currentAlarmId=100549|friendlyName=SBIU3/SVID1_02|eventTime=20 081024101406|probableCause=ClientFailure]ALARM_NOTIF[notificationType=alarmPurge|purgeAlarmsLi st={100549}]ALARM_NOTIF[notificationType=alarmRaise|currentAlarmId=100550|friendlyName=SGSY N FRJ/ALA_01|neLocationName=|eventTime=20081024102144|eventType=communicationsAlarm|probableCa use=ClientFailure|perceivedSeverity=warning|additionalText=|specificProblems={}|acknowledgementStatus= ack|additionalInfo={1.3.6.1.4.1.12.2.2.20=inService|1.3.6.1.4.1.12.2.2.19=path}]ALARM_NOTIF[notificatio nType=alarmClear|currentAlarmId=100550|friendlyName=SGSYN FRJ/ALA_01|eventTime=20081024102243|probableCause=ClientFailure]ALARM_NOTIF[notificationType =alarmPurge|purgeAlarmsList={100550}]ALARM_NOTIF[notificationType=alarmClear|currentAlarmId=10 0532|friendlyName=SBIU3/SVID1_07|eventTime=20081024103828|probableCause=ClientFailure]ALARM_

119

120
NOTIF[notificationType=alarmPurge|purgeAlarmsList={100532}]ALARM_NOTIF[notificationType=alarm Raise|currentAlarmId=100552|friendlyName=BCR MLP/SP_01|neLocationName=|eventTime=20081024104653|eventType=communicationsAlarm|probableCau se=TransportIncomingFail|perceivedSeverity=major|additionalText=|specificProblems={}|acknowledgement Status=ack|additionalInfo={1.3.6.1.4.1.12.2.2.20=inService|1.3.6.1.4.1.12.2.2.19=path}]ALARM_NOTIF[not ificationType=alarmRaise|currentAlarmId=100551|friendlyName=BCR MLP/SP_01|neLocationName=|eventTime=20081024104649|eventType=communicationsAlarm|probableCau se=TransportFailure|perceivedSeverity=major|additionalText=|specificProblems={}|acknowledgementStatus= ack|additionalInfo={1.3.6.1.4.1.12.2.2.20=inService|1.3.6.1.4.1.12.2.2.19=path}]DATA_END_NOTIF[]HEA RTBEAT_CONF[]ALARM_NOTIF[notificationType=alarmRaise|currentAlarmId=100625|friendlyName=B CR PUR/SPA_01|neLocationName=|eventTime=20081028120554|eventType=communicationsAlarm|probableCause=Cli entFailure|perceivedSeverity=warning|additionalText=|specificProblems={}|acknowledgementStatus=ack|add itionalInfo={1.3.6.1.4.1.12.2.2.20=notInService|1.3.6.1.4.1.12.2.2.19=path}]ALARM_NOTIF[notificationTy pe=alarmClear|currentAlarmId=100625|friendlyName=BCR PUR/SPA_01|eventTime=20081028120738|probableCause=ClientFailure]ALARM_NOTIF[notificationType=alarmP urge|purgeAlarmsList={100625}]ALARM_NOTIF[notificationType=alarmRaise|currentAlarmId=100626|fri endlyName=BCR PUR/SPA_01|neLocationName=|eventTime=20081028121645|eventType=communicationsAlarm|probableCause=Cli entFailure|perceivedSeverity=warning|additionalText=|specificProblems={}|acknowledgementStatus=ack|add itionalInfo={1.3.6.1.4.1.12.2.2.20=notInService|1.3.6.1.4.1.12.2.2.19=path}]ALARM_NOTIF[notificationTy pe=alarmClear|currentAlarmId=100626|friendlyName=BCR PUR/SPA_01|eventTime=20081028122643|probableCause=ClientFailure]ALARM_NOTIF[notificationType=alarmP urge|purgeAlarmsList={100626}]ALARM_NOTIF[notificationType=alarmRaise|currentAlarmId=100627|fri endlyName=RB LME PTB/SJ_01|neLocationName=|eventTime=20081028123133|eventType=communicationsAlarm|probableCaus e=DegradedSignal|perceivedSeverity=warning|additionalText=|specificProblems={}|acknowledgementStatus =ack|additionalInfo={1.3.6.1.4.1.12.2.2.20=inService|1.3.6.1.4.1.12.2.2.19=path}]ALARM_NOTIF[notificati onType=alarmClear|currentAlarmId=100627|friendlyName=RB LME PTB/SJ_01|eventTime=20081028123242|probableCause=DegradedSignal]ALARM_NOTIF[notificationType =alarmPurge|purgeAlarmsList={100627}]ALARM_NOTIF[notificationType=alarmRaise|currentAlarmId=10 0628|friendlyName=BCR PUR/SPA_01|neLocationName=|eventTime=20081028130559|eventType=communicationsAlarm|probableCause=Cli entFailure|perceivedSeverity=warning|additionalText=|specificProblems={}|acknowledgementStatus=ack|add itionalInfo={1.3.6.1.4.1.12.2.2.20=notInService|1.3.6.1.4.1.12.2.2.19=path}] HEARTBEAT_CONF[]

121

Apndice 2. Contenido del atributo probableCause

A continuacin se introduce el contenido del atributo probableCause. Esta informacin se incluye en la tabla condition_Type en las base de datos de Netrac. En esta se incluye la traduccin de cada uno de los campos.
2.9.3.2.0.0.1 Adapter Error 2.9.3.2.0.0.2 Application Subsystem Failure 2.9.3.2.0.0.3 Bandwidth Reduced 2.9.3.2.0.0.4 Call Establishment Error 2.9.3.2.0.0.5 Communications Protocol Error 2.9.3.2.0.0.6 Communications Subsystem Failure 2.9.3.2.0.0.7 Configuration or Customization Error 2.9.3.2.0.0.8 Congestion 2.9.3.2.0.0.9 Corrupt Data 2.9.3.2.0.0.10 CPU Cycles Limit Exceeded 2.9.3.2.0.0.11 Data Set or Modem Error 2.9.3.2.0.0.12 Degraded Signal 2.9.3.2.0.0.13 DTE-DCE Interface Error 2.9.3.2.0.0.14 Enclosure Door Open 2.9.3.2.0.0.15 Equipment Malfunction 2.9.3.2.0.0.16 Excessive Vibration 2.9.3.2.0.0.17 File Error 2.9.3.2.0.0.18 Fire Detected 2.9.3.2.0.0.19 Flood Detected 2.9.3.2.0.0.20 Framing Error 2.9.3.2.0.0.21 Heating or Ventilation or Cooling System Problem 2.9.3.2.0.0.22 Humidity Unacceptable 2.9.3.2.0.0.23 Input Output Device Error 2.9.3.2.0.0.24 Input Device Error 2.9.3.2.0.0.25 LAN Error 2.9.3.2.0.0.26 Leak Detected 2.9.3.2.0.0.27 Local Node Transmission Error 2.9.3.2.0.0.28 Loss of Frame 2.9.3.2.0.0.29 Loss of Signal 2.9.3.2.0.0.30 Material Supply Exhausted 2.9.3.2.0.0.31 Multiplexer Problem 2.9.3.2.0.0.32 Out of Memory 2.9.3.2.0.0.33 Ouput Device Error 2.9.3.2.0.0.34 Performance Degraded 2.9.3.2.0.0.35 Power Problem 2.9.3.2.0.0.36 Pressure Unacceptable 2.9.3.2.0.0.37 Processor Problem 2.9.3.2.0.0.38 Pump Failure 2.9.3.2.0.0.39 Queue Size Exceeded 2.9.3.2.0.0.40 Receive Failure 2.9.3.2.0.0.41 Receiver Failure 2.9.3.2.0.0.42 Remote Node Transmission Error 2.9.3.2.0.0.43 Resource at or Nearing Capacity 2.9.3.2.0.0.44 Response Time Excessive 2.9.3.2.0.0.45 Retransmission Rate Excessive 2.9.3.2.0.0.46 Software Error 2.9.3.2.0.0.47 Software Program Abnormally Terminated 2.9.3.2.0.0.48 Software Program Error 2.9.3.2.0.0.49 Storage Capacity Problem 2.9.3.2.0.0.50 Temperature Unacceptable 2.9.3.2.0.0.51 Threshold Crossed 2.9.3.2.0.0.52 Timing Problem 2.9.3.2.0.0.53 Toxic Leak Detected 2.9.3.2.0.0.54 Transmit Failure 2.9.3.2.0.0.55 Transmitter Failure 2.9.3.2.0.0.56 Underlying Resource Unavailable 2.9.3.2.0.0.57 Version Mismatch 0 Indeterminate 1 AIS 2 Call Set Up Failure 3 Degraded Signal 4 Far End Receiver Failure 5 Framing Error 6 Loss Of Frame 7 Loss Of Pointer 8 Loss Of Signal 9 Payload Type Mismatch 10 Transmission Error 11 Remote Alarm Interface 12 Excessive BER 13 Path Trace Mismatch 14 Unavailable 15 Signal Label Mismatch 16 Loss Of MultiFrame 17 Transmit Failure 18 Drift Time 19 Holdover Mode 20 Unequipped 21 Free Running Mode 22 Early Warning Indication 25 Consequent AIs 26 Consequent Loss Of Signal 27 Consequent Excessive BER 28 Consequent Degraded Signal 29 Consequent Loss Of Frame 30 High Laser Temperature 31 Laser Degraded 32 Demodulator Fail

122
33 Demodulator LOS 35 Lapd Fail 36 Modulator Fail 37 Modulator LOS 39 Loss Of Clock 41 Diversity Failure 43 Low Ber 44 Consequent Tx Fail 45 Consequent Loss Of Multi Frame 46 Consequent Far End Receiver Failure 47 Unavailable Time 49 Unexpected Tributary Input Bit Rate 50 Underlying Resource Unavailable 51 Backplane Failure 52 Data Set Problem 53 Equipment Identifier Duplication 54 External IF Device Problem 55 Line Card Problem 56 Multiplexer Problem 57 NE Identifier Duplication 58 Power Problem 59 Processor Problem 60 Protection Path Failure 61 Receiver Failure 62 Replaceable Unit Missing 63 Replaceable Unit Type Mismatch 64 Synchronization Source Mismatch 65 Terminal Problem 66 Timing Problem 67 Transmitter Failure 68 Trunk Card Problem 69 Replaceable Unit Problem 70 Resource Isolation 71 Consequent Laser Degraded 72 Laser Failure 73 Pumping Laser Degradation 74 Temperature Out Of Range 75 Hardware Failure 80 Craft Terminal Connected 81 Default Configuration 82 Unconsistent Ne Configuration 83 Loss Of Configuration 85 Equipment Malfunction 86 Version Mismatch 87 Communications Protocol Error 88 Configuration Or Customization Error 90 Cpe Interface Software Mismatch 91 Unit Missing 92 Unit Problem 93 Refused Configuration 94 Software Key Missing 95 Software Key Modified 96 Terminal Shutdown Within 24H 97 Internal Interface Problem 98 Tx Ais Insertion Indication 99 Rx Ais Insertion Indication 101 Air Compressor Failure 102 Air Conditioning Failure 103 Air Dryer Failure 104 Battery Discharging 105 Battery Failure 106 Commercial Power Failure 107 Cooling Fan Failure 108 Engine Failure 109 Fire Detector Failure 110 Fuse Failure 111 Generator Failure 112 Low Battery Threshold 113 Pump Failure 114 Rectifier Failure 115 Rectifier High Voltage 116 Rectifier Low F Voltage 117 Ventilations System Failure 118 Enclosure Door Open 119 Explosive Gas 120 Fire 121 Flood 122 High Humidity 123 High Temperature 124 High Wind 125 Ice Build Up 126 Intrusion Detection 127 Low Fuel 128 Low Humidity 129 Low Cable Pressure 130 Low Temperature 131 Low Water 132 Smoke 133 Toxic Gas 151 Storage Capacity Problem 152 Memory Mismatch 153 Corrupt Data 154 Out Of CPU Cycles 155 Sfwr Environment Problem 156 Sfwr Download Failure 200 Synchro Supply Unit Fail 201 Optical Amplifier Fail Urgent 202 Optical Amplifier Fail Abnormal 203 Optical Amplifier Fail Non Urgent 204 Both External Batteries Fail 205 House Keeping 206 Fan Power Problem 207 Loss Of Modulation 208 Loss Of Saturation Signal 209 Consequent Loss Of Input Signal 210 Consequent Loss Of Output Signal 211 Tx Loss Of Frame 212 Rx Loss Of Frame 213 Tx Loss Of Multi Frame 214 Rx Loss Of Multi Frame 215 Tx Remote Alarm Indication 216 Rx Remote Alarm Indication 217 Rx Alarm Indication Signal 218 Auxiliary Pattern Detection

123
219 Master Input LOS 220 Threshold Crossed 221 Expansion Input LOS 222 Loss Of Input Signal 223 Loss Of Output Signal 224 Loss Of Rx Superv Channel 225 Loss Of Tx Superv Channel 226 Loss Of Channel 227 Loss Of Superv Channel 228 Ch23 Input LOS 229 Ch25 Input LOS 230 Ch27 Input LOS 231 Ch29 Input LOS 232 Ch31 Input LOS 233 Ch33 Input LOS 234 Ch35 Input LOS 235 Ch37 Input LOS 236 Ch43 Input LOS 237 Ch45 Input LOS 238 Ch47 Input LOS 239 Ch49 Input LOS 240 Ch51 Input LOS 241 Ch53 Input LOS 242 Ch55 Input LOS 243 Ch57 Input LOS 244 Propagation Alarm 245 Cable Alarm 246 Tone Missing 247 Receive Failure 249 Output Power problem 250 Optical Loss Of Tx Superv Channel 251 Loss Of Input Signal Inter Stage 252 Received SPV Channel Problem 253 Aux MS AIS Channel One 254 Aux MS FERF Channel One 255 Aux MS LapD Fail 256 Aux RS LapD Fail 257 Aux 2Mb Channel Problem 258 Received SPV Channel on EW side 259 Received SPV Channel on WE side 260 Aux East RS LapD Fail 261 Aux West RS LapD Fail 334 Tx Degraded 335 Excessive Ber Bip2 372 Local Synchronisation 373 External Synchronisation 374 Out Of Service Master 375 High BER 399 K2 Architecture Mismatch 407 Communication Subsystem Fail 451 Far End Receive Degraded 452 Far End Loss Of Clock 453 Far End Loss Of Line Trib Signal 454 Far End Loss Of Line Mux Signal 455 Consequent Timing Problem 456 Loss Of Data 457 Consequent Loss Of Data 458 Loss Of SDH Frame 459 RSR Inserted 460 RSR Received 461 RDI Detected 462 AMS Inserted 463 Fec Uncorrected Blocks 464 Marker Mismatch 465 Tx Clock Sync Loss 466 Rx Clock Sync Loss 467 AIS Detect Rx Channel One 468 AIS Detect Tx Channel One 469 Timing Problem Channel One 470 Loss Of Signal Channel One 471 AIS Detect Rx Channel Two 472 AIS Detect Tx Channel Two 473 Timing Problem Channel Two 474 Loss Of Signal Channel Two 475 Timing Pb Channel 64k One 476 Timing Pb Channel 64k Two 477 Timing Pb Channel 64k Three 478 Fault Flag Detected 479 Far End Transmit Fail 480 Fec Errors Synthesis 481 B1 Errors Synthesis 482 Optical Signal Degraded 483 Transmit Problem 500 Supply Breaker Failure 501 Scrambler Problem 502 Fec Buffer Overflow 504 External Shutdown 505 EM ProbableCause 506 Unavailable Card 507 Abnormal Conditions 508 Internal Bus Failure 509 Remote Inventory Failure 510 Configuration Module Missing 511 Mf Isolation 512 First Stage Pumping Laser Degradation 513 Second Stage Pumping Laser Degradation 514 Auxiliary Pumping Laser Degradation 601 Optical Input Power Threshold Crossed 602 Optical Output Power Threshold Crossed 603 Laser Temperature Threshold Crossed 604 Laser Bias Threshold Crossed 605 Laser Power Threshold Crossed 606 Fec 15m Threshold Crossed 607 Fec 1Day Threshold Crossed 608 Modex Polarization Threshold Crossed 609 Delayed Maintenance 610 Undelayed Maintenance 701 ASE Signal Drop 702 Loopback Discontinuity 703 Laser External Shutdown 705 Fec Correction Overflow 706 AMS 708 Temperature Unacceptable 750 Main Dc Supply Failure

124
751 Aux Dc Supply Failure 752 Pfe Very High Current 753 Pfe Very Low Current 754 Pfe Very High Voltage 755 Pfe Very Low Voltage 756 Pfe Earth Current Imbalance 757 Pfe System To Station Earth Limit Exceeded 758 Pfe Line Voltage Protector 759 Pfe Earth Line Protector 760 Pfe Emergency Shutdown 761 Pfe Converter Contactor Failure 762 Pfe Converter Output Failure 763 Pfe Station And System Earths Shorted 764 Pfe Station Earth Only 765 Pfe Dummy Load Shutdown 766 Pfe Calibration Problem 767 Pfe High Zener Current 768 Pfe Zener Switch Open 769 Pfe Line Unmonitored 770 Pfe Both Mpcs On Line 771 Pfe MpcB On Line 772 Pfe Software Shutdown 773 Pfe Station Earth Fault 774 High Battery Threshold 775 Pfe Generator Rack 1 Power Problem 776 Pfe Generator Rack 2 Power Problem 777 Pfe Generator Rack 3 Power Problem 778 Pfe Generator Rack 4 Power Problem 779 Pfe Generator Rack 1 Fault 780 Pfe Generator Rack 2 Fault 781 Pfe Generator Rack 3 Fault 782 Pfe Generator Rack 4 Fault 783 Pfe Ramp Step Fail 784 Pfe Ramp End Of Step Unstable 785 Pfe Earth Problem 786 Pfe Current Problem 787 Pfe Cable Open 788 Pfe Door Open 789 Pfe Deferred Power Problem 790 Pfe Configuration Problem 791 Pfe Inconsistent Position Information 792 Pfe Remote Esd Shunted 801 Consequent MSAIs 802 Consequent RXAIs 807 Optical Connector Cover Open 808 Main Optical Connector Cover Open 810 Excessive BER B1 811 Excessive BER B2 812 Excessive BER B3 813 Threshold Crossed 15 Min 814 Threshold Crossed 1 Day 850 Pfe Battery Volts High 851 Pfe Battery Volts Low 901 Link Identity Code Mismatch 902 Excessive BERW 903 Excessive BERE 904 Loss Of Clock Tx 905 Exercise Test Ok 906 Exercise Test Not Ok 907 Aps Failure 908 Media Dependent Mismatch 909 Pass Through Fail 910 Wavelength Out Of Lock 911 Wavelength Out Of Limit 912 Fec Uncorrected Error Threshold Crossed 15 Min 913 Fec Uncorrected Error Threshold Crossed 1 Day 914 Pump Laser Temperature Threshold Crossed 915 Pump Laser Power Threshold Crossed 916 Pump Laser Bias Threshold Crossed 917 Output Power Threshold Crossed 950 Pfe Low Voltage Threshold Crossed 951 Pfe High Voltage Threshold Crossed 952 Pfe High Current Threshold Crossed 953 Pfe Low Current Threshold Crossed 954 Pfe Current Share Threshold Crossed 1000 Unavailable Path Alarm 1001 K1-K2 Protocol Mismatch 1009 Pdh 8Mb AIS 1010 Pdh 8Mb LOF 1011 Pdh 8Mb FERF 1022 Rx Fail 1023 Tx Fail 2481 Far End PreEmphasis Problem 2482 Ne Type Mismatch 1.3.12.2.1006.54.0.0.0.1.20 remotePoweringHighCurrent 1.3.12.2.1006.54.0.0.0.1.21 remotePoweringLowCurrent 1.3.12.2.1006.54.0.0.0.1.22 unbalancedLoad 1.3.12.2.1006.54.0.0.0.1.23 tALPowerProblem 1.3.12.2.1006.54.0.0.0.1.24 aMSR 1.3.12.2.1006.54.0.0.0.1.25 slip 1.3.12.2.1006.54.0.0.0.1.26 cRCMismatch 1.3.12.2.1006.54.0.0.0.1.27 lossOfFrameX50 1.3.12.2.1006.54.0.0.0.1.28 aISM 1.3.12.2.1006.54.0.0.0.1.29 fERFM 1.3.12.2.1006.54.0.0.0.1.38 qInterfaceLossOfCommunication 1.3.12.2.1006.54.0.0.0.1.39 lossOfTimingSources 1.3.12.2.1006.54.0.0.0.1.40 userChannelLOS 1.3.12.2.1006.54.0.0.0.1.41 nationalUseLOS 1.3.12.2.1006.54.0.0.0.1.42 userChannelSlip 1.3.12.2.1006.54.0.0.0.1.43 nationalUseSlip 1.3.12.2.1006.54.0.0.0.1.44 unequipped 1.3.12.2.1006.54.0.0.0.1.45 frequencyOffset 1.3.12.2.1006.54.0.0.0.1.46 insideFailure 1.3.12.2.1006.54.0.0.0.1.47 outsideFailure 1.3.12.2.1006.54.0.0.0.1.48 serverSignalFailure 1.3.12.2.1006.54.0.0.0.1.49 pdhFailure 1.3.12.2.1006.54.0.0.0.1.72 rVGShortCircuitAlarm 1.3.12.2.1006.54.0.0.0.1.73 internalCommunicationProblem

125
1.3.12.2.1006.54.0.0.0.1.74 rVGlowOutputVoltage 1.3.12.2.1006.54.0.0.0.1.75 transmitterDegraded 1.3.12.2.1006.54.0.0.0.1.76 channelFailure 1.3.12.2.1006.54.0.0.0.1.77 auxiliaryUnitPb 1.3.12.2.1006.54.0.0.0.1.78 auxiliaryUnitPbDeferred 1.3.12.2.1006.54.0.0.0.1.79 replaceableUnitUnknown 1.3.12.2.1006.54.0.0.0.1.80 lossOfModulation 1.3.12.2.1006.54.0.0.0.1.81 temperatureOutOfRange 1.3.12.2.1006.54.0.0.0.1.134 batteryProtectionDisabled 1.3.12.2.1006.54.0.0.0.1.135 batteryDoorOpen 1.3.12.2.1006.54.0.0.0.1.136 unconfiguredEquipmentPresent 1.3.12.2.1006.54.0.0.0.1.200 versionMismatch 1.3.12.2.1006.54.0.0.0.1.201 sfwrUnitMissing 1.3.12.2.1006.63.1.0.0.1 resourceIsolation Server Signal Failure Housekeeping Alarm Loss Of Timing Sources Inside Failure MIB backup misaligned Frequency Offset ClientFailure TransportFailure TransportIncomingFailure BandwidthReduced ConnectivityProblem DegradedSignal DegradedProtection EquipmentFailure ExBer HDSLFailure MediaFailure OSCFailure TransportOutgoingFailure RPSFailure RSFailure ServerMediaFailure ThresholdCErr UnderProtDeg QualityTC15m QualityTC24h ConfMismatch mSConfMismatch TandemConnFail TC_IncomingFlr TC_OutgoingFlr TCDegSig TanConTCA15m TanConTCA24h ALR_NOT_ALIGN HP_ALR_ENABLE LP_ALR_ENABLE EML_NOT_REACH Remote Defect Indication

126

Apndice 3. Cdigo Fuente implementado en Gremlin

#toppack <AL_SDH_L> #exceptmax <FALSE> Pack Lf_al_sdh_l_ini : LookForMulti ("LIST_CUR_ALARMS_CONF[]\|START_UNSOL_ALARMS_CONF[]\|ALARM_NOTIF[\|DATA_END_ NOTIF[", 0, 0) { Out Export = Copy; } Switch Sw_alarm_confirmation (Lf_al_sdh_l_ini.Export) { "DATA_END_NOTIF[" : Pack End_sync : Nop { Pack Lp_End_sync : LenPack (0, 0) { Out Export = Copy; } } "LIST_CUR_ALARMS_CONF[]","START_UNSOL_ALARMS_CONF[]" : Pack Start_sync : Nop { Pack Lp_start_sync : LenPack (0, 0) { Out Export = Copy; } } "ALARM_NOTIF[" : Pack Np_Look_alarms : Nop { Pack Lf_message_ini : LookFor ("notificationType=", 0, 0, 0, 1) {} Pack Al_Notificationtype : Aligned { Out Export = Copy; } Pack Lf_atributEnd_1 : LookFor ("|", 0, 0, 0, 1) { Export = Copy; } Switch Sw_Notification_validation (Al_Notificationtype.Export) { "alarmList", "alarmClear", "alarmRaise" : Pack Np_Notificacion_accept : Nop { Pack Lf_atribut_2 : LookFor ("currentAlarmId=", 0, 0, 0, 1) {} Pack Al_currentalarmid : Aligned { Out Export = Copy; } Pack Lf_atribut_3 : LookFor ("|friendlyName=", 0, 0, 0, 1) {} Pack Al_friEndlyName : Aligned { Out Export = Copy; } Pack Lf_atributEnd_3 : LookFor ("|", 0, 0, 0, 1) {} Pack Mp_value_fn_ini_1 : Pmath (-2, "-", Al_friEndlyName.Size, 0) { Export = Atoi; } Pack Lp_back_value_fn_ini_1 : LenPack (Mp_value_fn_ini_1.Export, 0) {} Pack Lf_Look_char_1 : LookFor ("=", 0, 0, 0, 1) {} Pack Al_constant_1 : Aligned {} Pack Lfo_Look_char_2 : LookForOr ("-_/|", 0, 0) {} Pack Lp_prueba_a : LenPack (4, 0) {} Pack Lp_prueba_b : LenPack (3, 0) { Export = Copy; } Pack Mp_resta_prueba : Pmath (0, "-", 7, 0) { Export = Atoi; } Pack Lp_back_value_fn_ini_1_b : LenPack (Mp_resta_prueba.Export, 0) { Export = Copy; } Pack Mp_resta_1 : Pmath (3, "-", Al_constant_1.Size, 0) { Export = Atoi; } Switch Sw_get_friEndlyNameinfo (Lp_prueba_b.Export) { "ADM" :

127
Pack Np_extract_friEndlyName_descr : Nop { Pack Mp_value_fn_ini_2 : Pmath (-1, "-", Al_constant_1.Size, 0) { Export = Atoi; } Pack Lp_back_value_fn_ini_2 : LenPack (Mp_value_fn_ini_2.Export, 0) {} Pack Al_nelocation : Aligned { Out Export = Copy; } Pack Lfo_Look_char_3 : LookForOr ("/|", 0, 0) { Export = Copy; } Pack Mp_resta_2 : Pmath (-1, "-", Al_nelocation.Size, 0) { Export = Atoi; } Pack Lp_back_value_fn_ini_3 : LenPack (Mp_resta_2.Export, 0) {} Pack Al_location : Aligned { Out Export = Copy; } Pack Lf_Look_char_4 : LookFor ("-", 0, 0, 0, 1) {} Pack Al_topologytype : Aligned { Out Export = Copy; } Pack Lf_Look_char_5 : LookFor ("-", 0, 0, 0, 1) {} Pack Al_admName : Aligned { Out Export = Copy; } Pack Lf_Look_char_6 : LookFor ("-", 0, 0, 0, 1) {} Pack Al_admNumber : Aligned { Out Export = Copy; } Pack Lfo_Look_char_7 : LookForOr ("/|", 0, 0) { Export = Copy; } Pack Mp_value_fn_ini_3 : Pmath (3, "-", Al_topologytype.Size, 0) { Out Export = Atoi; } Switch Sw_get_admprob_location (Lfo_Look_char_7.Export) { "/" : Pack Np_extract_admproblemlocation_1 : Nop { Pack Al_admproblemlocation : Aligned { Out Export = Copy; } Pack Lfo_Look_char_extrac_1_1 : LookForOr ("/|", 0, 0) { Export = Copy; } Pack Mp_resta_3 : Pmath (-1, "-", Al_admproblemlocation.Size, 0) { Export = Atoi; } Pack Lp_back_admproblemlocation_ini_1 : LenPack (Mp_resta_3.Export, 0) {} Pack Lp_nextchar_extract_1_1 : LenPack (1, 0) { Export = Copy; } Switch Sw_especify_admproblemlocation (Lp_nextchar_extract_1_1.Export) { "r" : Pack Np_get_r_sr_sl : Nop { Pack Al_rackNumber : Aligned { Out Export = Copy; } Pack Lf_subrack : LookFor ("sr", 0, 0, 0, 1) {} Pack Al_subrackNumber : Aligned { Out Export = Copy; } Pack Lfo_Look_char_get_r_sr_sl_1 : LookForOr ("s/", 0, 0) {} Pack Lp_back_get_r_sr_sl_1 : LenPack (-1, 0) {} Pack Lp_slot : LenPack (2, 0) { Export = Copy; } Switch Sw_get_slot_board (Lp_slot.Export) { "sl" : Pack Np_get_slotNumber : Nop { Pack Lp_back_slotNumber_ini : LenPack (-1, 1) {} Pack Al_slotNumber : Aligned { Out Export = Copy; } Pack Lf_nextchar_get_slotNumber_1 : LookFor ("/", 0, 0, 0, 1) {} Pack Al_sdhtpinfo : Aligned { Out Export = Copy; } Pack Lf_nextchar_get_slot_board_2 : LookFor ("|", 0, 0, 0, 1) {}

128
Pack Mp_resta_4 : Pmath (-2, "-", Al_sdhtpinfo.Size, 0) { Export = Atoi; } Pack Lp_back_get_slot_board_2 : LenPack (Mp_resta_4.Export, 0) {} Pack Lfo_nextchar_get_slot_board_3 : LookForOr ("/|", 0, 1) { Export = Copy; } Switch Sw_Look_sdhtpinfo (Lfo_nextchar_get_slot_board_3.Export) { "/" : Pack Np_sdhtpinfo_ok : Nop { Pack Al_tpName : Aligned { Out Export = Copy; } Pack Lf_findchar_sdhtpinfo_ok_1 : LookFor ("#", 0, 0, 0, 1) {} Pack Al_tpNumber : Aligned { Out Export = Copy; } Pack Lf_findchar_sdhtpinfo_ok_2 : LookFor ("-", 0, 0, 0, 1) {} Pack Lp_back_sdhtpinfo_0 : LenPack (-1, 0) {} Pack Lp_next_char_sdhtpinfo_0 : LenPack (2, 0) { Export = Copy; } Switch Sw_sdhtpinfo_type (Lp_next_char_sdhtpinfo_0.Export) { "-#" : Pack Np_logical_sdhtp_1 : Nop { Pack Lp_back_sdhtpinfo_1_1 : LenPack (-1, 0) {} Pack Al_logicalpOrtinfo : Aligned { Out Export = Copy; } Pack Lf_next_char_sdhtpinfo_1_2 : LookFor ("|", 0, 0, 0, 1) {} } Else : Pack Np_default_sdhtp_2 : Nop { Pack Lp_back_sdhtpinfo_2_1 : LenPack (-2, 0) {} Pack Lf_next_char_sdhtpinfo_2_1 : LookFor ("-", 0, 0, 0, 1) {} Pack Al_physicalpOrttype : Aligned { Out Export = Copy; } Pack Lf_next_char_sdhtpinfo_2_2 : LookFor ("|", 0, 0, 0, 1) {} } } } Else : Pack Np_sdhtpinfo_default : Nop {

129
Pack Lp_default_sdhtpinfo_2 : LenPack (0, 0) { Out Export = Copy; } } } } Else : Pack Np_get_boardNumber : Nop { Pack Lp_back_boardNumber_ini : LenPack (-1, 0) {} Pack Al_board : Aligned { Out Export = Copy; } Pack Lf_nextchar_get_boardNumber_1 : LookFor ("#", 0, 0, 0, 1) {} Pack Al_boardNumber : Aligned { Out Export = Copy; } Pack Lf_nextchar_get_boardNumber_2 : LookFor ("|", 0, 0, 0, 1) {} } } } Else : Pack Np_default_especify_admprobloc : Nop { Pack Lp_default_especify_admprobloc_1 : LenPack (-1, 0) {} Pack Lp_adMinfo : LenPack (4, 0) { Out Export = Copy; } Pack Lp_default_especify_admprobloc_back : LenPack (-4, 0) {} Switch Sw_extract_adMinfo (Lp_adMinfo.Export) { "ExtI", "T3T6" : Pack Np_extract_adMinfo_pOrt : Nop { Pack Al_admpOrtName : Aligned { Out Export = Copy; } Pack Lf_extract_adMinfo_pOrt_1 : LookFor ("#", 0, 0, 0, 1) {} Pack Al_admpOrtNumber : Aligned { Out Export = Copy; } Pack Lf_extract_adMinfo_pOrt_2 : LookFor ("|", 0, 0, 0, 1) {} Pack Lp_extract_adMinfo_pOrt_3 : LenPack (-1, 0) {} } Else : Pack Np_extract_adMinfo_default : Nop { Pack Lp_extract_adMinfo_default_1 : LenPack (0, 0) { Out Export = Copy; } } } } } } Else : Pack Np_extract_admproblemlocation_default : Nop { Pack Lp_extract_admproblemlocation_default_1 : LenPack (0, 0) { Out Export = Copy; } }

130
} } Else : Pack Np_get_friEndlyNameinfo_default : Nop { Pack Mp_get_friEndlyNameinfo_back_value : Pmath (-1, "-", Al_constant_1.Size, 0) { Export = Atoi; } Pack Lp_get_friEndlyNameinfo_back : LenPack (Mp_get_friEndlyNameinfo_back_value.Export, 0) {} Pack Al_nedefaultlocation : Aligned { Out Export = Copy; } Pack Lf_get_friEndlyNameinfo_default : LookFor ("|", 0, 0, 0, 1) {} Pack Mp_get_friEndlyNameinfo_back_value_1 : Pmath (-1, "-", Al_nedefaultlocation.Size, 0) { Export = Atoi; } Pack Lp_get_friEndlyNameinfo_back_1 : LenPack (Mp_get_friEndlyNameinfo_back_value_1.Export, 0) {} Pack Lp_get_maqueta_data : LenPack (6, 0) { Export = Copy; } } } Switch Sw_alarm_cases (Al_Notificationtype.Export) { "alarmList","alarmRaise" : Pack Np_alarm_list_raise : Nop { Pack Lf_atribut_4 : LookFor ("neLocationName=", 0, 0, 0, 1) {} Pack Al_nelocationName : Aligned { Out Export = Copy; } Pack Lf_atribut_5_1 : LookFor ("|eventTime=", 0, 0, 0, 1) {} Pack Al_eventtime_1 : Aligned { Out Export = Copy; } Pack Lf_nextchar_alarm_list_raise_1 : LookFor ("|", 0, 0, 0, 1) {} Pack Mp_resta_5 : Pmath (-1, "-", Al_eventtime_1.Size, 0) { Export = Atoi; } Pack Lp_back_alarm_list_raise_1 : LenPack (Mp_resta_5.Export, 0) {} Pack Lp_yyyy_1 : LenPack (4, 0) { Out Export = Copy; } Pack Lp_momo_1 : LenPack (2, 0) { Out Export = Copy; } Pack Lp_dd_1 : LenPack (2, 0) { Out Export = Copy; } Pack Lp_hh_1 : LenPack (2, 0) { Out Export = Copy; } Pack Lp_mimi_1 : LenPack (2, 0) { Out Export = Copy; } Pack Lp_ss_1 : LenPack (2, 0) { Out Export = Copy; } Pack Lf_atribut_6 : LookFor ("eventType=", 0, 0, 0, 1) {} Pack Al_eventtype : Aligned { Out Export = Copy; } Pack Lf_atribut_7_1 : LookFor ("|probableCause=", 0, 0, 0, 1) {} Pack Al_probablecause_1 : Aligned { Out Export = Copy; } Pack Lf_atribut_8 : LookFor ("|perceivedSeverity=", 0, 0, 0, 1) {} Pack Al_perceivedseverity : Aligned { Out Export = Copy; } Pack Lf_atribut_9 : LookFor ("|additionalText=", 0, 0, 0, 1) {} Pack Al_additionaltext : Aligned { Out Export = Copy; } Pack Lf_atribut_10 : LookFor ("|specificProblems=", 0, 0, 0, 1) {} Pack Al_specificproblems : Aligned { Out Export = Copy; } Pack Lf_atribut_11 : LookFor ("|acknowledgementStatus=", 0, 0, 0, 1) {} Pack Al_acknowledgementstatus : Aligned { Out Export = Copy; } Pack Lf_atribut_12 : LookFor ("|additionalInfo=", 0, 0, 0, 1) {} Pack Al_additionalinfo : Aligned { Out Export = Copy; } Pack Lf_atributEnd_12 : LookFor ("]", 0, 0, 0, 1) {}

131
Pack Mp_resta_7 : Pmath (0, "-", 1, 0) { Export = Atoi; } Pack Lp_back_attributEnd_12 : LenPack (Mp_resta_7.Export, 0) {} } "alarmClear" : Pack Np_alarm_clear : Nop { Pack Lf_atribut_5_2 : LookFor ("eventTime=", 0, 0, 0, 1) {} Pack Al_eventtime_2 : Aligned { Out Export = Copy; } Pack Lf_nextchar_alarm_clear_1 : LookFor ("|", 0, 0, 0, 1) {} Pack Mp_resta_6 : Pmath (-1, "-", Al_eventtime_2.Size, 0) { Export = Atoi; } Pack Lp_back_alarm_clear_1 : LenPack (Mp_resta_6.Export, 0) {} Pack Lp_yyyy_2 : LenPack (4, 0) { Out Export = Copy; } Pack Lp_momo_2 : LenPack (2, 0) { Out Export = Copy; } Pack Lp_dd_2 : LenPack (2, 0) { Out Export = Copy; } Pack Lp_hh_2 : LenPack (2, 0) { Out Export = Copy; } Pack Lp_mimi_2 : LenPack (2, 0) { Out Export = Copy; } Pack Lp_ss_2 : LenPack (2, 0) { Out Export = Copy; } Pack Lf_atribut_7_2 : LookFor ("probableCause=", 0, 0, 0, 1) {} Pack Al_probablecause_2 : Aligned { Out Export = Copy; } Pack Lf_atributEnd_7_2 : LookFor ("]", 0, 0, 0, 1) {} } Else : Pack Np_Not_alarm_1 : Nop { Pack Lp_default_4 : LenPack (0, 0) { Out Export = Copy; } } } } Else : Pack Np_Notification_refuse : Nop { Pack Lp_default_1 : LenPack (-1, 0) { Out Export = Copy; } } } Pack Lf_alarm_message_End : LenPack (0, 0) { Out Export = Copy; } } Else : Pack Np_Not_alarm_Notif : Nop { Pack Lp_Not_alarms_default : LookFor ("]", 0, 0, 0, 1) { Export = Copy; } } }

132

Apndice 4. Funciones diseadas para Troll

A continuacin se describen las funciones diseadas en la herramienta Troll para generar bloques de salida a partir de situaciones especiales.

A4.1 Converter
Esta funcin permite que cuando no se encuentre un valor en una tabla de Netrac, se devuelva como contenido la etiqueta indefinido. Cdigo:

Data Len; StringServiceStrLen(is_data_null, Len); if (Len==0) {os_data_correct="Indefinido"; os_longitud=Len;} else {os_data_correct=is_data_null; os_longitud=Len;} return true;

A4.2 Filtro_Description
Al crear en Troll la estructura del registro de salida ALR_Description no se tom en cuenta el caso de alarmas en trayectos. Para esto se cre esta funcin, la cual a partir de Ne_Index del gestor permite dejar pasar la estructura diseada para las alarmas del 1353NM o bien crear la descripcin formal de una alarma en un trayecto a partir su valor respectivo.

133 Cdigo:

Data DESCRIPTION; if (ii_Ne_Index==167196) { os_description=is_description; } else if (ii_Ne_Index==167197) { StringServiceStrCat15 ("",4,"ALARMA DE RUTA_ALCATEL en ",is_nedefaultLocation,"_Causa: ",is_probableCause," "," "," "," "," "," "," "," "," "," "," ", DESCRIPTION); os_description=DESCRIPTION; } else if (ii_Ne_Index==3908) { os_description=is_description; } else { os_description="IMPOSIBLE IDENTIFICAR ORIGEN DE LA ALARMA"; } return true;

A4.3 Filtro_physical_Id_ruta
Con el fin de asignar el valor del physical Id = RUTA_ALCATEL para los trayectos de red se cre esta funcin. Nuevamente el criterio para decidir si se asigna este valor es el contenido de Ne_Index. Cdigo:
if (ii_NE_index==167196) os_physical_ID=is_physical_ID; else if (ii_NE_index==167197) os_physical_ID="RUTA_ALCATEL"; else if (ii_NE_index==3908) os_physical_ID=is_physical_ID; else os_physical_ID=is_physical_ID; return true;

134

Apndice 5. Tablas para Netrac

A continuacin se dan los valores agregados a tablas o las tablas nuevas creadas en la base datos de Netrac (estas ltimas se indican como nueva en su ttulo).

A5.1 Tabla Priority_Convert

DEVICETYPE AL_SDH_L AL_SDH_L AL_SDH_L AL_SDH_L AL_SDH_L AL_SDH_L EXPVAL
Indeterminate Critical Major Minor Warning Cleared

PRIORITY 2 7 5 4 3 0

A5.2 Tabla LOOKUP_AL_SDH_DESC (NUEVA)

ID 1 2 3 4 5 6 7 8 9 10 11 ATTRIBUTE_VALUE ExtInP AT0SyncPu timingGenerator T0SyncPu P OpS EIS timi (pro ExtI T3T6 DESCRIPTION_ESP Alarmaenunpuertodelequipoporhousekeeping Relojexternoconectadoalequipo RelojInterno Prdidadereferenciadesincronizacindebidoaunfalloenel puerto ProblemaenunpuertoPDH ProblemaenunpuertopticoSDH ProblemaenunpuertoSDHElctrico Reloj/OsciladorInterno GruposyUnidadesdeProteccin PuertoExternodelADM PuertodeRelojexternoconectadoalequipo

135

A5.3 Tabla LOOKUP_AL_SDH_PID (NUEVA)

ID 1 2 3 4 5 6 7 NE_DEFAULT_LOCATION 1650_1 1650_2 1660_1 1660_2 1660_03 ItISAGENERATEDOVERFLOWALARM ItISAGENERATEDOVERFLOWALARM physical_ID 1650_1 1650_2 1660_1 1660_2 1660_03 1353NM 1354RM

A5.4 Tabla CONDITION_TYPE

Esta tabla no se muestra completamente debido a que contiene quinientas ocho filas. Se muestran las primeras cinco que se crearon. Las restantes consisten en las traducciones de los valores del atributo probableCause indicados en el Apndice 2.
ID 27 28 29 30 31 TECHNOLOGY CONDITION_CODE ALCATEL_SDH ALCATEL_SDH ALCATEL_SDH ALCATEL_SDH ALCATEL_SDH DESCRIPTION_ESP Alarmade communicationsAlarm Comunicacin AlarmadeCalidadde qualityofServiceAlarm Servicio AlarmadeErrorde processingErrorAlarm Procesamiento equipmentAlarm AlarmadeEquipo environmentAlarm DESCRIPTION_ENG TYPE

AlarmadeAmbiente